From ghc-devs at haskell.org Fri May 1 03:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 03:31:19 -0000 Subject: [GHC] #10368: Armhf/Linux : test T7815 failing Message-ID: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> #10368: Armhf/Linux : test T7815 failing -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- During validation on armhf/linux, I found this test had failed. Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like: {{{ for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo $? ; done }}} one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 times. The two boards are: * Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU. * Radxa Rock with a Rockchip RK3199 CPU. The ifc6540 is the one that fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 04:19:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 04:19:49 -0000 Subject: [GHC] #10368: Armhf/Linux : test T7815 failing In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.5e5d1b1c5e8d4b5c9b11ca3893c30015@haskell.org> #10368: Armhf/Linux : test T7815 failing -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #7815 | -------------------------------------+------------------------------------- Changes (by erikd): * related: => #7815 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 05:32:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 05:32:33 -0000 Subject: [GHC] #10368: Armhf/Linux : test T7815 failing In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.7f97f263e3447b130c975448d97b455a@haskell.org> #10368: Armhf/Linux : test T7815 failing -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #7815 | -------------------------------------+------------------------------------- Comment (by erikd): There is a pretty good explanation of weak vs strong memory models here : http://preshing.com/20120930/weak-vs-strong-memory-models/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 09:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 09:41:01 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.05ffb651eebc943e2ef19ec8d93f82a6@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * status: infoneeded => new Comment: Austin, can you land this please? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 09:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 09:41:21 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.b542c29a4fdfc39a8f59e8b2aaad49de@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 10:20:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 10:20:56 -0000 Subject: [GHC] #10369: arm binaries have an executable stack Message-ID: <044.2b00a277994bcc0061cf34807001386a@haskell.org> #10369: arm binaries have an executable stack -----------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------- Test `T703` is currently failing on on armhf/linux. The test result shows: {{{ GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0 }}} Arm compiles via LLVM, but x86_64 executbles compiled via LLVM do not have an executable stack. The other difference between the x86_64 and Arm is the Arm uses `ld.gold` as the linker. Sure enough, adding `-optl -Wl,-z,noexecstack` to the ghc command line fixes this, but a better solution is needed. This is probably also an issue on AArch64 which also uses the `ld.gold` linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 10:24:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 10:24:38 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.9d3e67c13cf53ea0824afdf375abfe5d@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * cc: ezyang (added) Comment: @ezyang : What do you think of the idea of adding the required ld command line args to `ld flags` field of the ghc `settings` file (when using `ld.gold`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 11:57:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 11:57:32 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.ab34763c8cd3046e5ee21864f4dae2f5@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): sounds like it makes sense to 1) put fma in Num and 2) add ghc primitive support to applicable supported microarchitectures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 17:03:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 17:03:52 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.05cd908191408af9f8b7b2d0edff211c@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:17 goldfire]: > I've updated [wiki:Typeable]. See the new Proposed API section, and the new Step 3. I'd like to note that if the proposed API is to help with Step 3 aka this ticket, either `trCon` or your suggested `tyConRep` needs to take a `TTypeRep k` argument. The "How can we get a TTyCon for a known-at-compile-time tycon?" was something I also stumbled on when trying to think of an API. Curiously if you simplify this a bit by removing `TTyCon` (`>_> <_<`), there is a nice ''end-user'' way of writing this from what's on the wiki page: {{{ x :: TTypeRep k -> TTypeRep (Proxy :: k -> *) x tt = withTypeable tt tTypeRep }}} Of course this just calls back into the entire machinery that's being implemented, so cannot be used as a basis. However, it means that the primitive desugaring of this may not need to be exposed to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 17:09:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 17:09:24 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.67755c0834c6b7bdf088490f8ceec1e8@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Mailing list post to libraries here: https://mail.haskell.org/pipermail/libraries/2015-May/025600.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 18:42:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 18:42:29 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.573260b68b60e092572607fafd8ec25f@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Some clarifications: 1. It would appear that we always do GhcMake dependency analysis when linking (there does not seem to be a way to feed GHC a list of object files to link together and coax it to skip linking), so it is sufficient to check that some correctness condition applies to boot files in the import graph. 2. If B is imported by another module which is not used by anyone, this will not cause the overlap check to find the overlap. So the condition is, more accurately, for each boot file, the implementing file must be transitively imported from the root of the module graph. I'm pretty sure (1) is easiest to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 19:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 19:01:05 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.a2df4e62bddcb96eb513aa4352c11f6a@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): > There does not seem to be a way to feed GHC a list of object files to link together and coax it to skip linking Actually, this is not true: {{{ ezyang at sabre:~$ ghc -c A.hs ezyang at sabre:~$ ghc -c B.hs-boot ezyang at sabre:~$ ghc -c C.hs ezyang at sabre:~$ ghc -c B.hs ezyang at sabre:~$ ghc -c D.hs ezyang at sabre:~$ ghc -c Main.hs ezyang at sabre:~$ ghc Main.o A.o B.o C.o D.o -o Unsafe ezyang at sabre:~$ ./Unsafe -5692549928996289131 }}} Unfortunately, GHC has no idea about the dependency structure of the object files; for all it knows, it could have been produced by another compiler. So there actually is no way for GHC to figure out that `B.o` is type-unsafe in this case. This would imply the only way to safely link Haskell objects is to use `ghc Main.hs` (which will do dependency resolution.) Note that Richard's original proposed fix will work in this case, since `B.hs` will be refused as `B.hs-boot` doesn't report enough type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 19:25:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 19:25:07 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw Message-ID: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As reported by Paolo Veronelli: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. I've had a look and indeed the file takes way more memory to compile with HEAD. Looking at the heap profiles, it seems that the problem is in GHC itself (space leak somewhere?). I'll attach the heap profiles (from compiling the single module itself, i.e., `touch`ing the file and running prof GHC on it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 20:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 20:58:09 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.c7e5a9f6c4af4c69cfcd7466a1f239bc@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is something curious: {{{ ezyang at sabre:~/Dev/haskell/T9562/p$ ghc --make D -fforce-recomp [1 of 5] Compiling A ( A.hs, A.o ) [2 of 5] Compiling B[boot] ( B.hs-boot, B.o-boot ) [3 of 5] Compiling C ( C.hs, C.o ) [4 of 5] Compiling B ( B.hs, B.o ) [5 of 5] Compiling D ( D.hs, D.o ) B.hs:8:15: Conflicting family instance declarations: type instance F a b -- Defined at B.hs:8:15 type instance F a b -- Defined at D.hs:8:15 }}} however, {{{ ezyang at sabre:~/Dev/haskell/T9562/p$ ghc --make B C D A -fforce-recomp [1 of 5] Compiling A ( A.hs, A.o ) [2 of 5] Compiling B[boot] ( B.hs-boot, B.o-boot ) [3 of 5] Compiling C ( C.hs, C.o ) [4 of 5] Compiling D ( D.hs, D.o ) [5 of 5] Compiling B ( B.hs, B.o ) }}} I don't know why in the latter case no error is reported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:39:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:39:52 -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.de3a0001ed133bbc631ad0839abd2398@haskell.org> #703: all binaries built by ghc have executable stacks -------------------------------------+------------------------------------- Reporter: duncan | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: T703 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * testcase: N/A => T703 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:40:11 -0000 Subject: [GHC] #10371: GHC fails to inline and specialize a function Message-ID: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> #10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have an alternative Prelude library called [subhask](https://github.com/mikeizbicki/subhask) that redefines the numeric type class hierarchy. I'm trying to update it to work with GHC 7.10, but there is a major inlining bug that is killing performance. The code below demonstrates the issue. It first defines a distance function over 2 vectors, then measures the performance using criterion. (It requires the subhask to compile.) {{{ {-# LANGUAGE BangPatterns #-} import Control.DeepSeq import Criterion.Main import qualified Data.Vector.Unboxed as VU import qualified Data.Vector.Generic as VG import qualified Prelude import SubHask -- distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float distance_standalone v1 v2 = sqrt $ go 0 0 where go !tot !i = if i>VG.length v1-4 then goEach tot i else go tot' (i+4) where tot' = tot +(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) +(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) *(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) +(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) *(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) +(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) *(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) goEach !tot !i = if i>= VG.length v1 then tot else goEach tot' (i+1) where tot' = tot+(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) main = do let v1 = VU.fromList [1..200] :: VU.Vector Float v2 = VU.fromList [1..200] :: VU.Vector Float deepseq v1 $ deepseq v2 $ return () defaultMain [ bench "distance_standalone" $ nf (distance_standalone v1) v2 ] }}} Here are the results of compiling and running using GHC 7.10 and 7.8: {{{ $ ghc-7.10.1 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 8.135 ?s (8.121 ?s .. 8.154 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 8.188 ?s (8.158 ?s .. 8.250 ?s) std dev 139.3 ns (66.05 ns .. 250.4 ns) variance introduced by outliers: 15% (moderately inflated) }}} {{{ $ ghc-7.8.2 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 733.2 ns (732.9 ns .. 733.6 ns) 1.000 R? (1.000 R? .. 1.000 R?) mean 734.1 ns (733.7 ns .. 734.5 ns) std dev 1.458 ns (1.262 ns .. 1.754 ns) }}} As you can see, GHC 7.10 is 10x slower. Looking through the core output shows that the cause of this is that GHC 7.8 is properly specializing the code whereas GHC 7.10 is not. If you uncomment the type signature before the `distance_standalone` function then both compilers perform at the faster speed. I believe the cause of this may be related to the complicated class numeric class hierarchy in SubHask. If you comment out the lines: {{{ import qualified Prelude import SubHask }}} then GHC uses the Prelude hierarchy instead of SubHask's hierarchy, and both compilers generate the faster program. There's one last wrinkle. If you define the `distance_standalone` function in a different file. Then in GHC 7.10, the `INLINE` and `INLINABLE` pragmas do absolutely nothing. Not only does the resulting code not get inlined, but if I add the specialization: {{{ {-# SPECIALIZE distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float #-} }}} to the Main file, I get an error message saying something like: {{{ bench/Vector.hs:18:1: Warning: You cannot SPECIALISE ?distance_standalone{v ru1}? because its definition has no INLINE/INLINABLE pragma (or its defining module ?subhask-0.1.0.0 at subha_LNZiQvSbo8Z0VdLTwuvkrN:SubHask.Algebra? was compiled without -O) }}} I get this message despite the fact that the defining module was compiled with `-O2` and the function had an `INLINABLE` pragma. If I add the specialization pragma to the defining module, then I don't get the warning, but the code still doesn't specialize properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:44:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:44:04 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.f6cbe079a1a7e07d149a97db46381dab@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:47:05 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.2ccfefd7a008d957385a134d3b72ecd5@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): @rwbarton suggests checking if the same problem exists when using `ld.gold` on x86_64/linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:49:16 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.214f7ce3502a7824ec26326bdddd8d09@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9562 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Actually, the situation is a bit better here, because hs-boot operates strictly locally. Here is a fix proposal: For non-orphan instances, we can't easily tell if an instance is supposed to be in scope unless we know whether or not the defining module is transitively reachable from the imports of a module. Fortunately, in `--make`, we do know this information from the import graph. So, for each module we compile, calculate a set of local hs/hs-boot modules which should be visible, and pass that along to the type-checker. Then, like for orphans, we only treat an instance as visible if it is in this set. (Note: we can't do this strategy for external instances, because we don't have the full dependency graph anymore.) I thought of this technique when I noticed that `--make` behavior was inconsistent, depending on whether or not a module was compiled before or after we retypecheck an hs-boot loop; if you always make sure modules which transitively have a `{-# SOURCE #-}` import on a booted module are type-checked BEFORE you typecheck the real implementation (even if there isn't a dependency), you will ensure that only the correct interfaces are in scope. But this is awfully delicate and wouldn't work well in the parallel make case, so just calculating the reachable set of nodes seems better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 1 23:57:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 May 2015 23:57:59 -0000 Subject: [GHC] #10372: panic! compiling Y combinator with optimizations Message-ID: <042.4bc4d3ef8e2b09a054daf4f8f20341b2@haskell.org> #10372: panic! compiling Y combinator with optimizations -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic, | Operating System: Unknown/Multiple simplifier | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following causes GHC 7.6.3, 7.8.3 and 7.10.1 (at least) to panic when compiling with optimizations: {{{#!hs module Y (y) where newtype Rec a = Rec { out :: Rec a -> a} k x = out x x y f = (f . k) (Rec (f . k)) }}} {{{ /tmp ??? ghc -O y.hs -fforce-recomp [1 of 1] Compiling Y ( y.hs, y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone a_sof 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: 5282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 00:23:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 00:23:06 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." (was: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression on MacOS platform) In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.416b0f60841af628058031bb75703a09@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 04:03:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 04:03:36 -0000 Subject: [GHC] #10373: Haiku: ghc-stage1 compiler crashes at exit Message-ID: <047.14cb3af31b0bb30eca2387ac61262b1c@haskell.org> #10373: Haiku: ghc-stage1 compiler crashes at exit -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Other Architecture: x86 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- When trying to build GHC on Haiku, the ghc-stage1 compiler will occasionally crash whilst shutting down the GHC RTS. However, if mk/build.mk is modified to EXCLUDE the vanilla way (GhcLibWays = dyn), then the ghc-stage1 compiler will NOT crash. Attached is a debug report of an example crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 04:12:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 04:12:56 -0000 Subject: [GHC] #10374: Can't build GHC with a dynamic only GHC installation Message-ID: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> #10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When an installation of GHC doesn't include the vanilla "way", GHC cannot be built from this existing installation of GHC. E.g. using the following mk/build.mk: {{{ V = 0 GhcLibWays = dyn SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 DYNAMIC_BY_DEFAULT = YES NoFibWays = STRIP_CMD = : }}} Steps to reproduce: 1. build & install GHC using above configuration 2. rebuild GHC using above configuration, --with-ghc pointing to the installation created in step 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 04:19:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 04:19:17 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages In-Reply-To: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> References: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> Message-ID: <068.b04e1e5e179292fa39036bc55a791152@haskell.org> #8414: ghc-pkg prevents dynamic library only packages -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jessicah): FWIW, I run a dynamic only installation of GHC on Haiku (no vanilla libs for GHC or packages installed via Cabal), and have not had any issues. However, I have not run ghc-pkg register manually. So maybe this is fixed? (This was with 7.8) The only caveat I've discovered is that you cannot build a new version of GHC using a dynamic-only GHC installation (see #10374). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 04:57:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 04:57:50 -0000 Subject: [GHC] #10374: Can't build GHC with a dynamic only GHC installation In-Reply-To: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> References: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> Message-ID: <062.720ef3d1c8159a64b3efb57a9c938a10@haskell.org> #10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by jessicah: Old description: > When an installation of GHC doesn't include the vanilla "way", GHC cannot > be built from this existing installation of GHC. > > E.g. using the following mk/build.mk: > {{{ > V = 0 > GhcLibWays = dyn > SRC_HC_OPTS = -O -H64m > GhcStage1HcOpts = -O -fasm > GhcStage2HcOpts = -O2 -fasm > GhcHcOpts = -Rghc-timing > GhcLibHcOpts = -O2 > > DYNAMIC_BY_DEFAULT = YES > > NoFibWays = > STRIP_CMD = : > }}} > > Steps to reproduce: > 1. build & install GHC using above configuration > 2. rebuild GHC using above configuration, --with-ghc pointing to the > installation created in step 1 New description: When an installation of GHC doesn't include the vanilla "way", GHC cannot be built from this existing installation of GHC: make[1]: *** No rule to make target `/packages/ghc_x86-7.8.3-10/.self/lib/x86/ghc-7.8.3/base-4.7.0.1/Prelude.hi', needed by `utils/hsc2hs/dist/build/Main.o'. Stop. E.g. using the following mk/build.mk: {{{ V = 0 GhcLibWays = dyn SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 DYNAMIC_BY_DEFAULT = YES NoFibWays = STRIP_CMD = : }}} Steps to reproduce: 1. build & install GHC using above configuration 2. rebuild GHC using above configuration, --with-ghc pointing to the installation created in step 1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 08:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 08:40:52 -0000 Subject: [GHC] #10371: GHC fails to inline and specialize a function In-Reply-To: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> References: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> Message-ID: <065.571cb5376a1e8bd131bf3363c8de6370@haskell.org> #10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8668 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MikeIzbicki): * related: => #8668 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 10:20:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 10:20:22 -0000 Subject: [GHC] #10371: GHC fails to inline and specialize a function In-Reply-To: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> References: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> Message-ID: <065.617f334c7d623c85327acb985b4a4bb7@haskell.org> #10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8668 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): I figured out a solution that works for me. Inside my class hierarchy there were several definitions that are similar to type synonyms: {{{ class (Rg r, Group r) => Rng r instance (Rg r, Group r) => Rng r }}} instead of: {{{ type Rng r = (Rg r, Group r) }}} Replacing these definitions with actual type synonyms fixed the problem. I was using the original version for two reasons. First, GHC 7.8 lacks ConstraintKinds support in TemplateHaskell. This is obviously not relevant after the upgrade to 7.10. Second, There are places where I would prefer to be able to partially apply the constraint, which you can't do as a type synonym. I can live without partial application, but it would be nice to have back. Unfortunately, these class definitions are not the sole cause of the problem. I tried recreating the relevant subset of my class hierarchy in another file. But I couldn't reproduce the problem using only this subset of code. So these classes must somehow be interacting with another part of the library which (seems to be) unrelated. Tracking down this other cause and giving a nice short test case here seems like more work than I can put into this since I have a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 2 15:04:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 15:04:49 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.6cc74708462f0af34b483fe91324e32a@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Comment (by ion1): I encountered the following on GHC 7.10.1, looks like it might be the same bug: {{{ % ghc -ignore-dot-ghci -fdefer-typed-holes -e 'map (\a b -> undefined) _' :1:25: Warning: Found hole ?_? with type: [a0] Where: ?a0? is an ambiguous type variable Relevant bindings include it :: [t -> t1] (bound at :1:1) In the second argument of ?map?, namely ?_? In the expression: map (\ a b -> undefined) _ In an equation for ?it?: it = map (\ a b -> undefined) _ :1:25: Warning: Found hole ?_? with type: [a0] Where: ?a0? is an ambiguous type variable Relevant bindings include it :: [t -> t2] (bound at :1:1) In the second argument of ?map?, namely ?_? In the expression: map (\ a b -> undefined) _ In an equation for ?it?: it = map (\ a b -> undefined) _ : : panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): nameModule $dShow_aMc 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 2 19:26:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 May 2015 19:26:30 -0000 Subject: [GHC] #10366: Post link to MacOS binary of 7.10 In-Reply-To: <047.96813fefee3197627308f4e0ad81012c@haskell.org> References: <047.96813fefee3197627308f4e0ad81012c@haskell.org> Message-ID: <062.1c744d9fb24c4436372d17f575c81880@haskell.org> #10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: highest | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): The same for PowerPC 64-bit Linux: The files are on the server, but the links are missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 3 18:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 May 2015 18:08:30 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.71f7521a992d3e509a56c43c11efc074@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michalt): I've had another quick look at this and compiled profiled GHC with addition of `{-# OPTIONS_GHC -fprof-auto #-}` to simplCore/Simplify.hs. The results are interesting: {{{ Sun May 3 17:33 2015 Time and Allocation Profiling Report (Final) ghc +RTS -hc -L100 -p -RTS [...] Graphics.Rendering.OpenGL.Raw.Functions total time = 42.38 secs (42385 ticks @ 1000 us, 1 processor) total alloc = 65,222,063,200 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc tc_rn_src_decls TcRnDriver 15.1 10.4 completeCall.(...) Simplify 9.5 22.0 simplCast.add_coerce.arg' Simplify 9.1 21.8 pprNativeCode AsmCodeGen 4.2 3.2 Parser HscMain 3.3 4.2 RegAlloc AsmCodeGen 3.0 2.7 regLiveness AsmCodeGen 2.5 2.0 simplLam Simplify 2.5 1.3 OccAnal SimplCore 2.5 1.8 StgCmm HscMain 2.3 1.2 CallArity SimplCore 2.2 3.4 FloatOutwards SimplCore 1.7 1.1 sink CmmPipeline 1.7 1.1 simplAlts Simplify 1.5 0.8 genMachCode AsmCodeGen 1.5 0.9 deSugar HscMain 1.5 1.3 simplAlt Simplify 1.4 0.7 simplUnfolding Simplify 1.3 0.8 layoutStack CmmPipeline 1.2 0.9 completeCall.info Simplify 1.2 0.6 completeBind Simplify 1.2 0.6 NativeCodeGen CodeOutput 1.2 0.8 rebuildCall Simplify 1.1 1.0 Simplify SimplCore 1.1 0.0 }}} Looking at git blame the Simplify.simplCast didn't change much recently... Next week I'll try to have a look at Core generated by 7.8.4 and HEAD (maybe some stage before simplifier generates something weird?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 3 21:14:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 May 2015 21:14:32 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.1a24147986c0fb34eeae08134c09dcd6@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): There was quite a bit of discussion and feedback on the mailing list, that I very much appreciated. See here: https://mail.haskell.org/pipermail/libraries/2015-May/025597.html Based on the analysis, I think this proposal should be shelved for the time being. And thus, I'm closing this feature-request. For the record, I'm quoting the final message from the above discussion. {{{ Thank you for all the feedback on this proposal. Based on the feedback, I came to conclude that the original idea did not really capture what I really was after, and hence I think this proposal needs to be shelved for the time being. I want to summarize the points made so far: * Almost everyone agrees that we should have this functionality available. (But see below for the direction I want to take it in.) * There's some disagreement on the name chosen, but I think this is less important for the time being. * The biggest gripe is where does "fma" really belong. Original suggestion was 'RealFloat', but people pointed 'Num' is just a good place as well. * Most folks want a default definition, and see "fma" as an optimization. It is these last two points actually that convinced me this proposal is not really what I want to have. I do not see "fma" as an optimization. In particular, I'd be very concerned if the compiler substituted "fma x y z" for "x*y+z". The entire reason why IEEE754 has an fma operation is because those two expressions have different values in general. By the same token, I'm also against providing a default implementation. I see this not as an increased-precision issue, but rather a semantic one; where "x*y+z" and "fma x y z" *should* produce two different values, per the IEEE754 spec. It's not really an optimization, but how floating-point values work. In that sense "fma" is a separate operation that's related to multiplication and addition, but is not definable in those terms alone. Having said that, it was also pointed out that for non-float values this can act as an optimization. (Modular arithmetic was given as an example.) I'd think that functionality is quite different than the original proposal, and perhaps should be tackled separately. My original proposal was not aiming for that particular use case. My original motivation was to give Haskell access to the floating-point circuitry that hardware-manufacturers are putting a lot of effort and energy into. It's a shame that modern processors provide a ton of instructions around floating-point operations, but such operations are simply very hard to use from many high-level languages, including Haskell. Two other points were raised, that also convinced me to seek an alternative solution: * Tikhon Jelvis suggested these functions should be put in a different class, which suggests that we're following IEEE754, and not some idealized model of numbers. I think this suggestion is spot on, and is very much in line with what I wanted to have. * Takebonu Tani kindly pointed that a discussion of floats in the absence of rounding-modes is a moot one, as the entire semantics is based on rounding. Haskell simply picks "RoundNearestTiesToEven," but there are 4 other rounding modes defined by IEEE754, and I think we need a way to access those from Haskell in a convenient way. Based on this analysis, I'm withdrawing the original proposal. I think fma and other floating-point arithmetic operations are very important to support properly, but it should not be done by tacking them on to Num or RealFloat; but rather in a new class that also considers rounding-mode properly. The advantage of the "separate" class approach is, of course, I (or someone else) can create such a class and push it on to hackage, using FFI to delegate the task of implementation to the land-of-C, by supporting rounding modes and other floating-point weirdness appropriately. Once that class stabilizes and its details are ironed out, then we can imagine cooperating with GHC folks to actually bypass the FFI and directly generate native code whenever possible. This is the direction I intend to move on. Please drop me a line if you'd like to help out and/or have any feedback. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 3 21:16:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 May 2015 21:16:07 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.e795fe46e5537ad553f1efb66faaff74@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: wontfix | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lerkok): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 3 23:55:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 May 2015 23:55:02 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.afc8aabf9727988bd867c1d374486fff@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Tested this on x86_64 by hacking `aclocal.m4` to add `x86_64` to `arm` and `aarch64`, then configured and checked that the `settings` file contained: {{{ ("C compiler link flags", " -fuse-ld=gold"), ("ld command", "/usr/bin/ld.gold"), }}} built the compiler and then ran test `T703` and it passed. So, when using `ld.gold` on `x86_64` we do not end up with an executable stack. This seems like an Arm specific problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 00:06:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 00:06:18 -0000 Subject: [GHC] #9564: Floating point subnormals overrounded on output In-Reply-To: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> References: <042.1dbf5d45edc6a6390ece467dc3a96b9e@haskell.org> Message-ID: <057.f58eeab269075c62c53ffd5c9d6792a8@haskell.org> #9564: Floating point subnormals overrounded on output -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Revisiting this ticket, I still think that GHC's output `1.0e-45` is correct, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 00:09:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 00:09:04 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.2b50ec8892441a88cdc34ddc930774ab@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: wontfix | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Be aware (if you aren't already) that GHC does not do any management of floating-point control registers, so functions called through FFI should take care to clean up their floating-point state, otherwise the rounding mode can change unpredictably at the level of Haskell code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 00:47:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 00:47:23 -0000 Subject: [GHC] #10375: arm: ghci.debugger tests hit illegal instruction Message-ID: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> #10375: arm: ghci.debugger tests hit illegal instruction ---------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------------- Some GHCi tests on arm/linux ie: {{{ (cd testsuite ; make TEST="print018 print020 print021 print022 print025") }}} fail, all with the same error: {{{ Stderr: Illegal instruction }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 00:50:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 00:50:13 -0000 Subject: [GHC] #10375: arm: ghci.debugger tests hit illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.68b777334a6e46e391de29c517dda9ab@haskell.org> #10375: arm: ghci.debugger tests hit illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Old description: > Some GHCi tests on arm/linux ie: > > {{{ > (cd testsuite ; make TEST="print018 print020 print021 print022 print025") > }}} > > fail, all with the same error: > > {{{ > Stderr: > Illegal instruction > }}} New description: Some GHCi tests on arm/linux ie: {{{ (cd testsuite ; make TEST="print018 print020 print021 print022 print025") }}} fail, all with the same error: {{{ Stderr: Illegal instruction }}} -- Comment (by erikd): Tests `ghci053 ghcirun001 ghcirun002`also fail in the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 01:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 01:13:24 -0000 Subject: [GHC] #10376: arm/linux linking failure Message-ID: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> #10376: arm/linux linking failure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Tests `sigcabal01` and `sigcabal02` both fail with an error like: {{{ /usr/bin/ld.gold: warning: cannot scan executable section 1 of \ /home/erikd/ghc-upstream/testsuite/tests/cabal/sigcabal01/inst-p/lib/\ arm-linux-ghc-7.11.20150501/p_F3lh2Js8iHV9qItpHBsq0d/\ libHSp-1.0-F3lh2Js8iHV9qItpHBsq0d.a(P.o) for Cortex-A8 erratum because it has no mapping symbols. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 01:44:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 01:44:06 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.f3d8d517f50606aa5b8a9420b151209d@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 02:31:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 02:31:13 -0000 Subject: [GHC] #10375: arm: ghci.debugger tests hit illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f2538c0681d982f66552d8ccaba4ac16@haskell.org> #10375: arm: ghci.debugger tests hit illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): The tests failures for `ghci053 ghcirun001 ghcirun002` all seem to be instances of the same failure, and can be boiled down to a mimimal example of: {{{ data Planet = Mercury | Venus deriving Eq Mercury == Mercury }}} Deriving Eq followed by a comparison is enough to cause GHCi to die with `Illegal instruction`. Turning this script into a program, compiling it and running the program works as it should. This is purely a GHCi issue, quite possibly the run time linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 03:20:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 03:20:39 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.a12f4de2a5668b3d475deef0d002f53e@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I created a synthetic test case that exhibits the same space blow-up: {{{ modu = unlines $ "module Out where" : "import Control.Monad (forever)" : [ var ++ " :: IO (); " ++ var ++ " = forever $ putStrLn \"" ++ var ++ "\"" | n <- [1..3000], let var = "a" ++ show n ] main = writeFile "Out.hs" modu }}} The string literals seem to be important, I didn't manage to find a variation that blew up without them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 04:19:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 04:19:44 -0000 Subject: [GHC] #10377: Remove double negative of ("Unregisterised", "NO") Message-ID: <044.31181ac18eac612460803bc88434cef8@haskell.org> #10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `settings` file has variable named `Unregisterised` which on most arches is sed to `NO`. I propose that the variable be renamed to `Registered` (dropping the "ised" part as well) so that: {{{ Old New ("Unregisterised", "NO") -> ("Registered", "YES") ("Unregisterised", "YES") -> ("Registered", "NO") }}} Unless someone can come up with a good reason why it should stay as it is, I will submit a patch for this to phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 04:22:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 04:22:19 -0000 Subject: [GHC] #10377: Remove double negative of ("Unregisterised", "NO") In-Reply-To: <044.31181ac18eac612460803bc88434cef8@haskell.org> References: <044.31181ac18eac612460803bc88434cef8@haskell.org> Message-ID: <059.c9aa7d725f4669461abb7440c64a6a19@haskell.org> #10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): May even make more sense to rename the variable `GhcCallingConvention`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 04:59:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 04:59:04 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction (was: arm: ghci.debugger tests hit illegal instruction) In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.15dbf65df94131dcb0bfa791676474f6@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 05:08:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 05:08:42 -0000 Subject: [GHC] #3046: Generalized newtype deriving with associated types In-Reply-To: <053.5760498fe5df42ff01ed60b4c8b401f4@haskell.org> References: <053.5760498fe5df42ff01ed60b4c8b401f4@haskell.org> Message-ID: <068.33eae0ceb3ae57ed5631067db0c4a7cb@haskell.org> #3046: Generalized newtype deriving with associated types -------------------------------------+------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * failure: => None/Unknown Comment: I don't think this is a duplicate of #2850, but I do think it is a duplicate of #8165. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 05:45:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 05:45:37 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect Message-ID: <045.4765ac29584fe513da96250006286137@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell does not satisfy this property. Furthermore, the current definitions are not commutative, when given `NaNs` and `-0` arguments. The following cases demonstrate the issue with `max`, but `min` has the exact same problems. {{{#!hs Prelude> (0/0) `max` 5 NaN Prelude> 5 `max` (0/0) 5.0 Prelude> isNegativeZero ((-0) `max` 0) False Prelude> isNegativeZero (0 `max` (-0)) True }}} It wouldn't be hard to fix the definitions appropriately; here are reference implementations that are IEEE754 compliant: {{{#!hs maxH x y | isNaN x = y | isNaN y = x | x > y || (x == y && isNegativeZero y) = x | True = y minH x y | isNaN x = y | isNaN y = x | x < y || (x == y && isNegativeZero x) = x | True = y }}} Note that these reference implementations would be quite expensive if GHC were to use them directly. Luckily, IEEE754 compliant min/max operations are supported by all modern CPUs, so doing the "right" thing here is also the cheaper thing as well. (i.e., it'll even be faster than the current incorrect implementation.) On platforms that do not have hardware implementations, the above definitions can serve as the correct implementations, albeit they'll be slower. (Embedded devices, perhaps.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 05:46:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 05:46:38 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.cd65288c20bb6966801c47705c530300@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell does not satisfy this property. > > Furthermore, the current definitions are not commutative, when given > `NaNs` and `-0` arguments. > > The following cases demonstrate the issue with `max`, but `min` has the > exact same problems. > > {{{#!hs > Prelude> (0/0) `max` 5 > NaN > Prelude> 5 `max` (0/0) > 5.0 > Prelude> isNegativeZero ((-0) `max` 0) > False > Prelude> isNegativeZero (0 `max` (-0)) > True > }}} > > It wouldn't be hard to fix the definitions appropriately; here are > reference implementations that are IEEE754 compliant: > > {{{#!hs > maxH x y > | isNaN x = y > | isNaN y = x > | x > y || (x == y && isNegativeZero y) = x > | True = y > > minH x y > | isNaN x = y > | isNaN y = x > | x < y || (x == y && isNegativeZero x) = x > | True = y > }}} > > Note that these reference implementations would be quite expensive if GHC > were to use them directly. Luckily, IEEE754 compliant min/max operations > are supported by all modern CPUs, so doing the "right" thing here is also > the cheaper thing as well. (i.e., it'll even be faster than the current > incorrect implementation.) > > On platforms that do not have hardware implementations, the above > definitions can serve as the correct implementations, albeit they'll be > slower. (Embedded devices, perhaps.) New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Furthermore, the current definitions are not commutative, when given `NaNs` and `-0` arguments. The following cases demonstrate the issue with `max`. Note that `min` has the exact same problems. {{{#!hs Prelude> (0/0) `max` 5 NaN Prelude> 5 `max` (0/0) 5.0 Prelude> isNegativeZero ((-0) `max` 0) False Prelude> isNegativeZero (0 `max` (-0)) True }}} It wouldn't be hard to fix the definitions appropriately; here are reference implementations that are IEEE754 compliant: {{{#!hs maxH x y | isNaN x = y | isNaN y = x | x > y || (x == y && isNegativeZero y) = x | True = y minH x y | isNaN x = y | isNaN y = x | x < y || (x == y && isNegativeZero x) = x | True = y }}} Note that these reference implementations would be quite expensive if GHC were to use them directly. Luckily, IEEE754 compliant min/max operations are supported by all modern CPUs, so doing the "right" thing here is also the cheaper thing as well. (i.e., it'll even be faster than the current incorrect implementation.) On platforms that do not have hardware implementations, the above definitions can serve as the correct implementations, albeit they'll be slower. (Embedded devices, perhaps.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 05:47:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 05:47:16 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.52e54173d3eb23366681c17b1de0f651@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell do not satisfy this property. > > Furthermore, the current definitions are not commutative, when given > `NaNs` and `-0` arguments. > > The following cases demonstrate the issue with `max`. Note that `min` has > the exact same problems. > > {{{#!hs > Prelude> (0/0) `max` 5 > NaN > Prelude> 5 `max` (0/0) > 5.0 > Prelude> isNegativeZero ((-0) `max` 0) > False > Prelude> isNegativeZero (0 `max` (-0)) > True > }}} > > It wouldn't be hard to fix the definitions appropriately; here are > reference implementations that are IEEE754 compliant: > > {{{#!hs > maxH x y > | isNaN x = y > | isNaN y = x > | x > y || (x == y && isNegativeZero y) = x > | True = y > > minH x y > | isNaN x = y > | isNaN y = x > | x < y || (x == y && isNegativeZero x) = x > | True = y > }}} > > Note that these reference implementations would be quite expensive if GHC > were to use them directly. Luckily, IEEE754 compliant min/max operations > are supported by all modern CPUs, so doing the "right" thing here is also > the cheaper thing as well. (i.e., it'll even be faster than the current > incorrect implementation.) > > On platforms that do not have hardware implementations, the above > definitions can serve as the correct implementations, albeit they'll be > slower. (Embedded devices, perhaps.) New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Furthermore, the current definitions are not commutative, when given `NaNs` and `-0` arguments. The following cases demonstrate the issue with `max`. Note that `min` has the exact same problems. {{{#!hs Prelude> (0/0) `max` 5 NaN Prelude> 5 `max` (0/0) 5.0 Prelude> isNegativeZero ((-0) `max` 0) False Prelude> isNegativeZero (0 `max` (-0)) True }}} It wouldn't be hard to fix the definitions appropriately; here are reference implementations that are IEEE754 compliant: {{{#!hs max x y | isNaN x = y | isNaN y = x | x > y || (x == y && isNegativeZero y) = x | True = y min x y | isNaN x = y | isNaN y = x | x < y || (x == y && isNegativeZero x) = x | True = y }}} Note that these reference implementations would be quite expensive if GHC were to use them directly. Luckily, IEEE754 compliant min/max operations are supported by all modern CPUs, so doing the "right" thing here is also the cheaper thing as well. (i.e., it'll even be faster than the current incorrect implementation.) On platforms that do not have hardware implementations, the above definitions can serve as the correct implementations, albeit they'll be slower. (Embedded devices, perhaps.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 05:47:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 05:47:38 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.9dfd390b9467471e5c2db077c98d7901@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell do not satisfy this property. > > Furthermore, the current definitions are not commutative, when given > `NaNs` and `-0` arguments. > > The following cases demonstrate the issue with `max`. Note that `min` has > the exact same problems. > > {{{#!hs > Prelude> (0/0) `max` 5 > NaN > Prelude> 5 `max` (0/0) > 5.0 > Prelude> isNegativeZero ((-0) `max` 0) > False > Prelude> isNegativeZero (0 `max` (-0)) > True > }}} > > It wouldn't be hard to fix the definitions appropriately; here are > reference implementations that are IEEE754 compliant: > > {{{#!hs > max x y > | isNaN x = y > | isNaN y = x > | x > y || (x == y && isNegativeZero y) = x > | True = y > > min x y > | isNaN x = y > | isNaN y = x > | x < y || (x == y && isNegativeZero x) = x > | True = y > }}} > > Note that these reference implementations would be quite expensive if GHC > were to use them directly. Luckily, IEEE754 compliant min/max operations > are supported by all modern CPUs, so doing the "right" thing here is also > the cheaper thing as well. (i.e., it'll even be faster than the current > incorrect implementation.) > > On platforms that do not have hardware implementations, the above > definitions can serve as the correct implementations, albeit they'll be > slower. (Embedded devices, perhaps.) New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Furthermore, the current definitions are not commutative, when given `NaNs` and `-0` arguments. The following cases demonstrate the issue with `max`. Note that `min` has the exact same problems. {{{#!hs Prelude> (0/0) `max` 5 NaN Prelude> 5 `max` (0/0) 5.0 Prelude> isNegativeZero ((-0) `max` 0) False Prelude> isNegativeZero (0 `max` (-0)) True }}} It wouldn't be hard to fix the definitions appropriately; here are reference implementations that are IEEE754 compliant: {{{#!hs max x y | isNaN x = y | isNaN y = x | x > y || (x == y && isNegativeZero y) = x | True = y min x y | isNaN x = y | isNaN y = x | x < y || (x == y && isNegativeZero x) = x | True = y }}} Note that these reference implementations would be quite expensive if GHC were to use them directly. Luckily, IEEE754 compliant min/max operations are supported by all modern CPUs, so doing the "right" thing here is also the cheaper thing as well. (i.e., it'll even be faster than the current incorrect implementation.) On platforms that do not have hardware implementations, the above definitions can serve as the correct implementations, albeit they'll be slower. (Embedded devices, perhaps.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:12:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:12:19 -0000 Subject: [GHC] #10379: Prefix syntax for promoted list kind isn't parsed properly Message-ID: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> #10379: Prefix syntax for promoted list kind isn't parsed properly -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- (Originally from https://stackoverflow.com/questions/27673578/) Given the following input file: {{{ {-# LANGUAGE KindSignatures, GADTs, DataKinds, TypeOperators #-} data Foo1 :: [*] -> * where data Foo2 :: ([] *) -> * where }}} it fails on the definition of `Foo2`: {{{ list-promote2.hs:4:16: parse error on input `]' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:16:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:16:03 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages In-Reply-To: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> References: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> Message-ID: <068.20942868f901bfca0372f9a98c738694@haskell.org> #8414: ghc-pkg prevents dynamic library only packages -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:16:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:16:39 -0000 Subject: [GHC] #10374: Can't build GHC with a dynamic only GHC installation In-Reply-To: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> References: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> Message-ID: <062.628455dd42f0d4cf3d6ba3b14655480d@haskell.org> #10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:20:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:20:11 -0000 Subject: [GHC] #4479: Implement Dot as Postfix Function Apply In-Reply-To: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> References: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> Message-ID: <059.3df55af03871aed400a6a7f036a2fdd0@haskell.org> #4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.5 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:21:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:21:00 -0000 Subject: [GHC] #4800: Memory Leak when Compiling qtHaskell In-Reply-To: <044.ee1af1cd10ac65da1eed8d844eae3073@haskell.org> References: <044.ee1af1cd10ac65da1eed8d844eae3073@haskell.org> Message-ID: <059.1f9acfdda0cf52f5051c84ea35f0a394@haskell.org> #4800: Memory Leak when Compiling qtHaskell -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash | developer.berlios.de/project/showfiles.php?group_id=10072 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:21:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:21:10 -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.42934a987f38c974874f442629aca130@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.12.1 Resolution: | Version: 7.7 Operating System: Windows | Keywords: Type of failure: GHC doesn't work | Architecture: at all | Unknown/Multiple Blocked By: | Test Case: cabal01 Related Tickets: #7134 | Blocking: 6107 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:21:24 -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.124bbdd0917eeebf736d4f9f331b86fa@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.8.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9282 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:21:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:21:46 -0000 Subject: [GHC] #4370: Bring back monad comprehensions In-Reply-To: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> References: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> Message-ID: <061.a14dea9c2804d17ac3477298f0d3ca36@haskell.org> #4370: Bring back monad comprehensions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:22:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:22:03 -0000 Subject: [GHC] #4482: Allow type variables to be instantiated as a typeclass In-Reply-To: <044.9706e6ecd3397e8f65f6d148e5341f1c@haskell.org> References: <044.9706e6ecd3397e8f65f6d148e5341f1c@haskell.org> Message-ID: <059.069402282d7dd12e8ef33cdd9300f646@haskell.org> #4482: Allow type variables to be instantiated as a typeclass -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler (Type | Version: 6.12.3 checker) | Keywords: Resolution: wontfix | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:23:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:23:15 -0000 Subject: [GHC] #4483: Offside rule for function definitions In-Reply-To: <044.8b87d41b40a9add2003d43564b8d44a6@haskell.org> References: <044.8b87d41b40a9add2003d43564b8d44a6@haskell.org> Message-ID: <059.af15c9396427ec9b6bf3fed4f156dba7@haskell.org> #4483: Offside rule for function definitions -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:23:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:23:58 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.9f41bc20bf8f7759b326a4792dd39e7f@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:24:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:24:27 -0000 Subject: [GHC] #8012: Warn when using Enum instance for Float or Double In-Reply-To: <044.0e03682649ff2f7d67a58f07a2aa0a0c@haskell.org> References: <044.0e03682649ff2f7d67a58f07a2aa0a0c@haskell.org> Message-ID: <059.bc55d3cce63f92c1ed3ca31e7504d962@haskell.org> #8012: Warn when using Enum instance for Float or Double -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:24:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:24:40 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.ed4a7b0bfda3245facdc5cf3678ac169@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:24:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:24:58 -0000 Subject: [GHC] #8026: DatatypeContexts should be fixed, not deprecated In-Reply-To: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> References: <044.a122d516f8e952d1dc31de7c6d1be31a@haskell.org> Message-ID: <059.92c8bcc71596a867437d416aff566c43@haskell.org> #8026: DatatypeContexts should be fixed, not deprecated -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:26:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:26:17 -0000 Subject: [GHC] #8085: Both GHC and its installer don't run on current Debian Stable In-Reply-To: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> References: <044.950a7a72a7ff9aabb202da185a28c46e@haskell.org> Message-ID: <059.74a94ff4d778c396f62db2cf60a834ed@haskell.org> #8085: Both GHC and its installer don't run on current Debian Stable -------------------------------------+------------------------------------- Reporter: ppetr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:26:29 -0000 Subject: [GHC] #8086: Minimal install for GHC In-Reply-To: <044.639a3d9529af624a90c978e5b689569d@haskell.org> References: <044.639a3d9529af624a90c978e5b689569d@haskell.org> Message-ID: <059.6dcb85900dc9db305ae0d6290f1a8ed6@haskell.org> #8086: Minimal install for GHC -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:26:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:26:55 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.15a11e804454965d83a6c9f928da3be7@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D172 -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:27:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:27:10 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.aa8488969e11068af002756e991ab681@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:27:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:27:22 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.18ecc74f08fc72c3967966f0937324c0@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8299 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:27:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:27:33 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.c6169148a7407aa9505cd5b0476bd3be@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:27:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:27:46 -0000 Subject: [GHC] #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 In-Reply-To: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> References: <044.561ba29e90addc2b60e1e644c2bc8bfa@haskell.org> Message-ID: <059.a93b8f0ef1c85a8072864f9199571b66@haskell.org> #8941: Module that causes GHC-7.8 to exhaust memory when compiled with -O2 -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@?, marco.vax91@?, jwlato@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:28:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:28:19 -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.76d4a212d3429719116dfd737d747815@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.12.1 Component: Compiler (NCG) | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:28:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:28:29 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.eb989231a24932dd4efef80bfc5a528d@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:28:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:28:49 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.ca423e208f3b142f2344306177ed5fca@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8731 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:36:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:36:13 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.82b63935543a952a41163cfe3c4a5b9b@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:37:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:37:45 -0000 Subject: [GHC] #9087: Executables in the Linux binaries are not stripped In-Reply-To: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> References: <045.32e06e6ec3c181db27d068784d01610c@haskell.org> Message-ID: <060.730376a169e24e1f03a7276376f94d6c@haskell.org> #9087: Executables in the Linux binaries are not stripped -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:38:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:38:08 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.4591761b76d2765249a3bac738972cea@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8731 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:38:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:38:30 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.63cc11bed4cf8f7ca171c3d5f365d7ff@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 8299 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:38:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:38:44 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.28302b24c39f03301087e5d047ed0d43@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:39:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:39:18 -0000 Subject: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o In-Reply-To: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> References: <045.e0a31be3fad6f397a63ade6e4c217e60@haskell.org> Message-ID: <060.10c065bb30701e39fb6997781b4e0811@haskell.org> #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 07:57:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 07:57:13 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.e4f995c9a98371b1fc0e6725242a6fb5@haskell.org> #10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 09:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 09:20:30 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket Message-ID: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- First start a TCP server, e.g. nc. {{{ % nc localhost -l 1234 > /dev/null }}} On another shell, compile the following program and run it: {{{ % ghc -threaded sock.hs % ./sock localhost 1234 receiver: thread blocked indefinitely in an MVar operation }}} {{{#!hs {-# LANGUAGE ViewPatterns #-} import Control.Applicative -- GHC 7.8 compatibility import Control.Concurrent import qualified Control.Exception as Ex import Control.Monad import qualified Data.ByteString.Char8 as S import Network.Socket import qualified Network.Socket.ByteString as Sock import Network.BSD (getHostByName, hostAddresses) import System.Environment import System.Mem main :: IO () main = do [host, read -> fromInteger -> port] <- getArgs sock <- connectTo host port forkVerbose "sender" $ forever $ do _ <- Sock.send sock $ S.replicate 40000 '0' return () forkVerbose "receiver" $ forever $ do dat <- Sock.recv sock 2048 putStrLn $ "received: " ++ show dat forever $ do threadDelay 1000000 performGC forkVerbose :: String -> IO () -> IO () forkVerbose name act = void $ forkIO $ do act; msg "exiting normally" `Ex.catch` \e -> msg $ show (e :: Ex.SomeException) where msg s = putStrLn $ name ++ ": " ++ s connectTo :: HostName -> PortNumber -> IO Socket connectTo hostName port = do addr <- SockAddrInet port <$> lookupHost hostName sock <- socket AF_INET Stream 0 connect sock addr return sock lookupHost :: String -> IO HostAddress lookupHost name = do hostInfo <- getHostByName name case hostAddresses hostInfo of [] -> error ("Invalid host name: " ++ name) (a:_) -> return a }}} GHC 7.8.3 doesn't have this problem. I suspect that this is a regression in the event manager. When there is an event, `GHC.Event.Manager.onFdEvent` seems to remove all callbacks associated to the `fd`, whether or not they match the current event. In the program above, the callback for `recv` may be removed permanently when the socket becomes ready for `send`ing, causing the "receiver" thread to deadlock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 11:58:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 11:58:42 -0000 Subject: [GHC] #10379: Prefix syntax for promoted list kind isn't parsed properly In-Reply-To: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> References: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> Message-ID: <060.3555112dc87ba470bfee93c58de78aa8@haskell.org> #10379: Prefix syntax for promoted list kind isn't parsed properly -------------------------------------+------------------------------------- Reporter: cactus | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * milestone: => 7.12.1 Comment: This is by design, for better or worse. Parsing in kinds is rather restricted. This will be fixed when I merge my kind equalities patch, which combines the type and kind parsers (among many other things). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:32:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:32:37 -0000 Subject: [GHC] #10377: Remove double negative of ("Unregisterised", "NO") In-Reply-To: <044.31181ac18eac612460803bc88434cef8@haskell.org> References: <044.31181ac18eac612460803bc88434cef8@haskell.org> Message-ID: <059.bf152b39b57d8af679b8e155768e67db@haskell.org> #10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In general I don't like making changes like this because the established terminology is found in documentation/papers/blog posts/StackOverflow answers and changing the terminology effectively reduces the value of all those resources. The term "Registered" in particular is not good since it already has a much more common meaning in the context of software. We don't want people thinking they have to register their copy of GHC! Personally I don't find `("Unregisterised", "NO")` confusing; I'm not sure why, but I think it might be because registerised is the "default", so unregisterised sticks out as a "positive", unusual property, despite the etymology. Consider also that unregisterised builds are enabled by `--enable-unregisterised`, we don't talk about disabling registerised- ness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:40:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:40:43 -0000 Subject: [GHC] #8414: ghc-pkg prevents dynamic library only packages In-Reply-To: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> References: <053.c57fa11cf8cece16048f38d65161c630@haskell.org> Message-ID: <068.fbf088e5d20e383b8410261e4e7d1e52@haskell.org> #8414: ghc-pkg prevents dynamic library only packages -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I can reproduce this in 7.6 but not 7.8, and I know at least one other person has been using a dynamic-only installation of 7.8, so I'm going to assert that this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:41:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:41:23 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.5803822b62bb375e235e059ffa79b7cb@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by Adam Gundry ): In [changeset:"4efa421327cf127ebefde59b2eece693e37dc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4efa421327cf127ebefde59b2eece693e37dc3c6" Permit empty closed type families Fixes #9840 and #10306, and includes an alternative resolution to #8028. This permits empty closed type families, and documents them in the user guide. It updates the Haddock submodule to support the API change. Test Plan: Added `indexed-types/should_compile/T9840` and updated `indexed-types/should_fail/ClosedFam4` and `th/T8028`. Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: bgamari, jstolarek, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D841 GHC Trac Issues: #9840, #10306 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:41:24 -0000 Subject: [GHC] #10306: Calling reify on Any or built-in type families causes panic In-Reply-To: <049.6556ac4af659c7bd1966731677057666@haskell.org> References: <049.6556ac4af659c7bd1966731677057666@haskell.org> Message-ID: <064.9da72b0d3110d9ff39bee5aa15f168da@haskell.org> #10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9840 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by Adam Gundry ): In [changeset:"4efa421327cf127ebefde59b2eece693e37dc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4efa421327cf127ebefde59b2eece693e37dc3c6" Permit empty closed type families Fixes #9840 and #10306, and includes an alternative resolution to #8028. This permits empty closed type families, and documents them in the user guide. It updates the Haddock submodule to support the API change. Test Plan: Added `indexed-types/should_compile/T9840` and updated `indexed-types/should_fail/ClosedFam4` and `th/T8028`. Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: bgamari, jstolarek, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D841 GHC Trac Issues: #9840, #10306 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:41:24 -0000 Subject: [GHC] #8028: Panic on degenerate closed type family In-Reply-To: <047.5d668fa575a5c9413b3e6498f94fd237@haskell.org> References: <047.5d668fa575a5c9413b3e6498f94fd237@haskell.org> Message-ID: <062.8bfad4d8e0c97f74346ef251e6f9c193@haskell.org> #8028: Panic on degenerate closed type family -------------------------------------------------+------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Adam Gundry ): In [changeset:"4efa421327cf127ebefde59b2eece693e37dc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4efa421327cf127ebefde59b2eece693e37dc3c6" Permit empty closed type families Fixes #9840 and #10306, and includes an alternative resolution to #8028. This permits empty closed type families, and documents them in the user guide. It updates the Haddock submodule to support the API change. Test Plan: Added `indexed-types/should_compile/T9840` and updated `indexed-types/should_fail/ClosedFam4` and `th/T8028`. Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: bgamari, jstolarek, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D841 GHC Trac Issues: #9840, #10306 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:45:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:45:24 -0000 Subject: [GHC] #10306: Calling reify on Any or built-in type families causes panic In-Reply-To: <049.6556ac4af659c7bd1966731677057666@haskell.org> References: <049.6556ac4af659c7bd1966731677057666@haskell.org> Message-ID: <064.bb60db688aea970fa83cde5c4f57c6db@haskell.org> #10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10306 Blocked By: | Blocking: Related Tickets: #9840 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => closed * testcase: => th/T10306 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:49:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:49:07 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.4a5927446daf05707c32f39c96f0a72d@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- Blocked By: | types/should_compile/T9840 Related Tickets: #8028 | Blocking: | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: patch => merge * testcase: => indexed-types/should_compile/T9840 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 14:57:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 14:57:15 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.987750f282ddd44d0624a1fca26bd20c@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Hi Levent, I think this is a duplicate of #9530, do you agree? There is some discussion there. I do think this is a topic worth discussing but I'm not sure Trac is the best place for it; for starters it's not clear that min on Float/Double *should* be IEEE754-compliant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 15:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 15:37:38 -0000 Subject: [GHC] #10227: Type checker cannot deduce type In-Reply-To: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> References: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> Message-ID: <062.6a798d778bf4fe4c86b54d535c30a81d@haskell.org> #10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: One can go arbitrarily far in this direction, so it's not obvious when to stop. I agree that `D d Double ~ Bool` seems like it should be easily solved, but what about something like `D d Double ~ D d Bool`? This also can hold only if `d ~ In`, which could be detected by unifying stuck closed type family applications with each branch in turn and noticing that all but one lead to inconsistencies. I think this approach makes sense in terms of "improvement", but representing evidence for it would be difficult, so it would be hard to handle givens as opposed to wanteds. Moreover, it might not be very efficient! If anyone would like to experiment, though, this seems like a nice application for typechecker plugins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 15:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 15:55:38 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.f6bbcd3ce7d9cd03502e7874b46cb2b9@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: It's a bug or limitation in the stream-fusion package. This simpler program has the same problem: {{{ import qualified Data.List.Stream as SL bad_sum :: [Int] -> Int bad_sum xs = if null xs then 0 else head xs + bad_sum (SL.tail xs) main = print $ bad_sum [1..20000] }}} The reason is this rewrite rule for `SL.tail`: {{{ {-# RULES "tail -> fusible" [~1] forall xs. tail xs = unstream (Stream.tail (stream xs)) --"tail -> unfused" [1] forall xs. -- unstream (Stream.tail (stream xs)) = tail xs #-} }}} Note that the second rule is commented out! So each recursive call adds a layer of something similar to `foldr (:) []` to the remainder of the list, and the total time is quadratic. You might submit a bug report on stream-fusion, though I don't know whether it is still maintained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 16:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 16:01:39 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.62acebecc507d3655f167cc1d3997963@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): (By the way, this was an issue of no optimizations versus -O2 (or -O), not -O versus -O2.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 17:09:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 17:09:50 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.a62db24147c2fa91b6fc523f8b320196@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: MarceColl Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by MarceColl): * owner: => MarceColl -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 17:55:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 17:55:36 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.4d9ec8ec8ee11eb58e9069258f0828d5@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Richard and I had a discussion, and we decided that solution 2 (when GHC is preparing the list of modules to send to the linker, perform an overlap check on type functions) is the only solution that works for linking together LIBRARY files (e.g. libfoo.a). Solution 1 does not work in this case, since when you link a library there isn't actually an executable to overlap check. This has a consequence that (at least for safe usage) you can't just use `ar` to put `.o` files together: you must call GHC to do the overlap check. This means we need a new major mode for GHC, to do the overlap check for a set of modules (or even to just do the linking). The overlap check should be implied when `--make` is used. It's harmless for `--make` to report an overlap early (as is the case currently), but we must always do overlap check at the end, in case `D` is compiled before `B` (as was the case in 7.8). The overlap check can be skipped if there are no boot files. Aside: There is an alternate strategy we can use which avoids the need for an overlap check at the very end. However, it requires that one-shot compilation be done in a ''specific'' order, so we don't think we should actually use it. Here's what you do: every `A.hs`/`A.hs-boot` pair induces a cycle of imports, which must be compiled before `A.hs` can be compiled. We ''always'' compile this cycle before we compile any other modules which depend on `A.hs-boot`. When compiling a module which transitively imports a boot file, we check if the real module has already been compiled; if so, we load it and add its instances to our environment. An instance which conflicts with the instance in `A.hs` will either be in a critical cycle, or not. If it is in the critical cycle, we will report overlap when `A.hs` is typechecked. Otherwise, we will load `A.hi` when typechecking the module and report overlap. One silly way to enforce this ordering is, when compiling a module which transitively depends on a boot file, to produce a pre-hi file; only when the real module has been compiled, only then can you re-process the hi file to produce the real hi file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 18:03:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 18:03:54 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.51a4c6df52dc8f7f666ebbe88c34a2cf@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): @rwbarton: Ah, thanks for that pointer, I'm not sure if it's a true duplicate (I didn't see a discussion of +0/-0 in there); but the tickets are indeed related. Feel free to close/merge. I definitely agree that we need more discussion on this. Since the other one is closed, perhaps this one can stay. PS. I just found out that the min/max implementation in Intel CPU's actually do not follow the reference implementation I gave in the ticket precisely. I'll put a note in there. Something else to discuss on how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 18:09:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 18:09:17 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.98d58549e5f70758d89b423c6f4616c5@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell do not satisfy this property. > > Furthermore, the current definitions are not commutative, when given > `NaNs` and `-0` arguments. > > The following cases demonstrate the issue with `max`. Note that `min` has > the exact same problems. > > {{{#!hs > Prelude> (0/0) `max` 5 > NaN > Prelude> 5 `max` (0/0) > 5.0 > Prelude> isNegativeZero ((-0) `max` 0) > False > Prelude> isNegativeZero (0 `max` (-0)) > True > }}} > > It wouldn't be hard to fix the definitions appropriately; here are > reference implementations that are IEEE754 compliant: > > {{{#!hs > max x y > | isNaN x = y > | isNaN y = x > | x > y || (x == y && isNegativeZero y) = x > | True = y > > min x y > | isNaN x = y > | isNaN y = x > | x < y || (x == y && isNegativeZero x) = x > | True = y > }}} > > Note that these reference implementations would be quite expensive if GHC > were to use them directly. Luckily, IEEE754 compliant min/max operations > are supported by all modern CPUs, so doing the "right" thing here is also > the cheaper thing as well. (i.e., it'll even be faster than the current > incorrect implementation.) > > On platforms that do not have hardware implementations, the above > definitions can serve as the correct implementations, albeit they'll be > slower. (Embedded devices, perhaps.) New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Unfortunately, the IEEE-spec isn't exactly clear on how min/max should work around +0/-0. It's deliberately underspecified. Most Intel implementations simply return the second argument in this case. So, the following would be the "reference" implementation, assuming we map to the Intel CPU instructions for floating-point min/max: {{{#!hs max x y | isNaN x = y | isNaN y = x | (x == 0) && (y == 0) = y | x > y = x | True = y min x y | isNaN x = y | isNaN y = x | (x == 0) &&& (y == 0) = y | x < y = x | True = y }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 18:13:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 18:13:15 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.a9273ebfb1c5aeca0b03f9bea4ad2724@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell do not satisfy this property. > > Unfortunately, the IEEE-spec isn't exactly clear on how min/max should > work around +0/-0. It's deliberately underspecified. Most Intel > implementations simply return the second argument in this case. So, the > following would be the "reference" implementation, assuming we map to the > Intel CPU instructions for floating-point min/max: > > {{{#!hs > max x y > | isNaN x = y > | isNaN y = x > | (x == 0) && (y == 0) = y > | x > y = x > | True = y > > min x y > | isNaN x = y > | isNaN y = x > | (x == 0) &&& (y == 0) = y > | x < y = x > | True = y > }}} New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Unfortunately, the IEEE-spec isn't exactly clear on how min/max should work around +0/-0. It's deliberately underspecified. Most Intel implementations simply return the second argument in this case. So, the following would be the "reference" implementation, assuming we map to the Intel CPU instructions for floating-point min/max: {{{#!hs max x y | isNaN x = y | isNaN y = x | (x == 0) && (y == 0) = y -- takes care of +/-0 | x > y = x | True = y min x y | isNaN x = y | isNaN y = x | (x == 0) &&& (y == 0) = y -- takes care of +/-0 | x < y = x | True = y }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 18:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 18:13:46 -0000 Subject: [GHC] #10378: min/max for Double/Float instances are incorrect In-Reply-To: <045.4765ac29584fe513da96250006286137@haskell.org> References: <045.4765ac29584fe513da96250006286137@haskell.org> Message-ID: <060.4a0e01155bffaf41a51c2562b74c829d@haskell.org> #10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > This is similar to many other numeric issues around `Double`s and > `Float`s. > > The IEEE754 requires `min` and `max` on floats to return the "other" > number, if one of the arguments is `NaN`. The default definitions used in > Haskell do not satisfy this property. > > Unfortunately, the IEEE-spec isn't exactly clear on how min/max should > work around +0/-0. It's deliberately underspecified. Most Intel > implementations simply return the second argument in this case. So, the > following would be the "reference" implementation, assuming we map to the > Intel CPU instructions for floating-point min/max: > > {{{#!hs > max x y > | isNaN x = y > | isNaN y = x > | (x == 0) && (y == 0) = y -- takes care of +/-0 > | x > y = x > | True = y > > min x y > | isNaN x = y > | isNaN y = x > | (x == 0) &&& (y == 0) = y -- takes care of +/-0 > | x < y = x > | True = y > }}} New description: This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell do not satisfy this property. Unfortunately, the IEEE-spec isn't exactly clear on how min/max should work around +0/-0. It's deliberately underspecified. Most Intel implementations simply return the second argument in this case. So, the following would be the "reference" implementation, assuming we map to the Intel CPU instructions for floating-point min/max: {{{#!hs max x y | isNaN x = y | isNaN y = x | (x == 0) && (y == 0) = y -- takes care of +/-0 | x > y = x | True = y min x y | isNaN x = y | isNaN y = x | (x == 0) && (y == 0) = y -- takes care of +/-0 | x < y = x | True = y }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 19:59:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 19:59:12 -0000 Subject: [GHC] #10381: Type-checking failure with RankNTypes and RebindableSyntax Message-ID: <047.d7142d6ce51d5a2d200ac502d303e59c@haskell.org> #10381: Type-checking failure with RankNTypes and RebindableSyntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RebindableSyntax, RankNTypes #-} module Bug where import Prelude ( String, undefined ) newtype Cont r a = Cont { runCont :: (forall i. a i -> r) -> r } (>>=) :: Cont r a -> (forall i. a i -> Cont r b) -> Cont r b ma >>= fmb = Cont (\k -> runCont ma (\a -> runCont (fmb a) k)) fail :: String -> Cont r a fail = undefined return :: a i -> Cont r a return x = Cont (\k -> k x) foo :: Cont r [] foo = do bar <- foo return bar }}} I get {{{ Bug.hs:21:3: Couldn't match type ?i0? with ?i? because type variable ?i? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [i] -> Cont r [] at Bug.hs:21:3-12 Expected type: Cont r [] -> ([i0] -> Cont r []) -> Cont r [] Actual type: Cont r [] -> (forall i. [i] -> Cont r []) -> Cont r [] In a stmt of a 'do' block: bar <- foo In the expression: do { bar <- foo; return bar } In an equation for ?foo?: foo = do { bar <- foo; return bar } }}} Yet, {{{ baz :: Cont r [] baz = baz >>= \bar -> return bar }}} at the end of this file compiles just fine. I had thought that `foo` and `baz` are entirely equivalent. Note that, with normal `do` notation, it ''is'' possible to do a GADT-like pattern-match with `<-`, without anyone's brain exploding. Some background: I'm attempting to write a type-checker for a simply-typed lambda calculus that uses GADTs to help me write the evaluation functions. The actual lambda-calculus bit has gone swimmingly; you can see it [https://github.com/goldfirere/glambda/blob/master/Language/Glambda/Exp.hs here]. But now I'm writing a type-checker, which has to take a possibly- ill-typed expression of type `UExp` and convert it to an `Exp ctx ty`, which is guaranteed to have type `ty` in context (a list of types) `ctx`. I can't just write {{{ check :: UExp -> Maybe (Exp '[] ty) }}} because the type has to be an ''output''. I could use existentials, but I find continuation-passing style to be easier to work with. But then the syntax goes all terrible. So, I want the `Cont` monad. Except that doesn't deal with these existentially-bound type variables at all. And, without doing any category theory, I have a very strong hunch that my CPS-with- extra-type-variables does not form a Monad. But, no matter, I'll just use `RebindableSyntax` and define my enhanced `Cont` not-a-monad with appropriate operators, and get my nice syntax back. But it doesn't work, as we see with this ticket. :( Clearly, this isn't really blocking me, but it makes me a touch sad not to use the nice syntax. `foo` fails to type-check in both 7.8 and 7.10, although the error messages are quite different (7.10 is an improvement). `baz` type-checks in both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 20:51:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 20:51:16 -0000 Subject: [GHC] #10382: Template Haskell quotes should work with stage 1 compiler Message-ID: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> #10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now, you must enable the `TemplateHaskell` extension to use quotes, and `TemplateHaskell` is not supported by the stage 1 compiler. But there actually is no good reason why this should be the case: quoting doesn't require any user-written code to be loaded up and run, so it should be doable by the stage 1 compiler. I propose adding a new extension, `Quotation`, which turns on JUST quotation and works with the stage 1 compiler. This will solve len's problem https://github.com/ekmett/lens/issues/496 where they want to rename some syntax using quotation, but don't want break compilation on a stage 1 compiler. See also #10279. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 22:16:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 22:16:25 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.e23c2c9f0d3ea3045485b3b672e8f999@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"63a10bbc42492c58feb377d79e05a185e6efcd5a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63a10bbc42492c58feb377d79e05a185e6efcd5a" arm: Force non-executable stack (#10369) Test `T703` was found to be failing on arm/linux. The solution was to add a linker flag to explicitly set the stack to non-executable. Signed-off-by: Erik de Castro Lopo Test Plan: validate on x86_64 and arm linux Reviewers: ezyang, rwbarton, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D875 GHC Trac Issues: #10369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 22:20:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 22:20:05 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.1a5bbc4014bb9af34c158f42a51cdeaf@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"bf4f3e653407d02593a69618fb199b2e2d529c92/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="bf4f3e653407d02593a69618fb199b2e2d529c92" Give a hint when a TH splice has a bad package key, partially fixes #10279 Previously, if we got a package key in our splice, we'd give a very unhelpful error message saying we couldn't find a package 'base-4.7.0.1', despite there being a package with that source package ID. Really, we couldn't find a package with that *key*, so clarify, and also tell the user what the real package key is. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 22:20:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 22:20:46 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.8deee886c0d8df4c8ad1861986adc35c@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * status: new => merge * milestone: 7.12.1 => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 22:21:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 22:21:16 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.852c6e4b48be08148f0487d000516361@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is the wiki page on the topic: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/PackageKeyChanges -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 22:26:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 22:26:47 -0000 Subject: [GHC] #10377: Remove double negative of ("Unregisterised", "NO") In-Reply-To: <044.31181ac18eac612460803bc88434cef8@haskell.org> References: <044.31181ac18eac612460803bc88434cef8@haskell.org> Message-ID: <059.6431b0c08cb0f3147c88e7e5e5e65268@haskell.org> #10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:2 rwbarton]: > Personally I don't find `("Unregisterised", "NO")` confusing; I'm hitting it all the time because I'm working on both armhf which is "registerised" and aarch64 which currently isn't (working on that). `("Unregisterised", "YES")` doesnt give me much trouble, but *every* time I see `("Unregisterised", "NO")` I have a huge double take and have to think about it. > unregisterised builds are enabled by `--enable-unregisterised`, we don't talk about disabling registerised-ness. No, but `--disable-ghc-calling-convention` is far more obvious than what we have now. Its also makes it more obvious that `ghc-calling-convention` is the *default*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 23:14:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 23:14:34 -0000 Subject: [GHC] #10382: Template Haskell quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.c7fc6d1f225cdb3e6731e6d457d47457@haskell.org> #10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D876 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 4 23:14:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 May 2015 23:14:53 -0000 Subject: [GHC] #10382: Template Haskell quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.1d5fcd5775fac650e2c77a0ef1d6b9c4@haskell.org> #10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Right now, you must enable the `TemplateHaskell` extension to use quotes, > and `TemplateHaskell` is not supported by the stage 1 compiler. But there > actually is no good reason why this should be the case: quoting doesn't > require any user-written code to be loaded up and run, so it should be > doable by the stage 1 compiler. I propose adding a new extension, > `Quotation`, which turns on JUST quotation and works with the stage 1 > compiler. > > This will solve len's problem https://github.com/ekmett/lens/issues/496 > where they want to rename some syntax using quotation, but don't want > break compilation on a stage 1 compiler. > > See also #10279. New description: Right now, you must enable the `TemplateHaskell` extension to use quotes, and `TemplateHaskell` is not supported by the stage 1 compiler. But there actually is no good reason why this should be the case: quoting doesn't require any user-written code to be loaded up and run, so it should be doable by the stage 1 compiler. I propose adding a new extension, `Quotes`, which turns on JUST quotation and works with the stage 1 compiler. This will solve len's problem https://github.com/ekmett/lens/issues/496 where they want to rename some syntax using quotation, but don't want break compilation on a stage 1 compiler. See also #10279. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 01:02:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 01:02:26 -0000 Subject: [GHC] #10381: Type-checking failure with RankNTypes and RebindableSyntax In-Reply-To: <047.d7142d6ce51d5a2d200ac502d303e59c@haskell.org> References: <047.d7142d6ce51d5a2d200ac502d303e59c@haskell.org> Message-ID: <062.02ca06126b9193c446c484abc345abc0@haskell.org> #10381: Type-checking failure with RankNTypes and RebindableSyntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shachaf): I can't test the code right now, but I'd expect `do { bar <- foo; return bar }` to mean `let { ok bar = return bar; ok _ = fail "..." } in foo >>= ok` as specified in the report. That could probably have rank-2 problems where a lambda doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 01:24:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 01:24:18 -0000 Subject: [GHC] #10381: Type-checking failure with RankNTypes and RebindableSyntax In-Reply-To: <047.d7142d6ce51d5a2d200ac502d303e59c@haskell.org> References: <047.d7142d6ce51d5a2d200ac502d303e59c@haskell.org> Message-ID: <062.5183e084f79f603cd436931f9d821cba@haskell.org> #10381: Type-checking failure with RankNTypes and RebindableSyntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Good point. But perhaps it's worth deviating from the report desugaring in the case where the LHS of the `<-` is a bare variable. Desugaring `a <- b; c` to `b >>= \a -> c` instead of the more verbose version seems to have the same runtime semantics but perhaps better compile-time behavior. Though this isn't ruining my day, as such, I'll name myself as a Real Client, for once, as this happened while doing something other than directly trying to befuddle GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 01:51:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 01:51:44 -0000 Subject: [GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN In-Reply-To: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> References: <042.94b3c8c54ebad9c2d01e3889791d7f50@haskell.org> Message-ID: <057.11dcf84bac80b27530f1fe9b9d1c021b@haskell.org> #9530: min / max do not always return the other argument when one of the arguments is NaN -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: 9276 | Blocking: Related Tickets: 9276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): I hate to beat a dead-horse; but in the light of the similarly filed ticket: https://ghc.haskell.org/trac/ghc/ticket/10378, I thought I'd put in my feedback. While Carter is right that the being compliant to the IEEE-spec might be useless, it is nonetheless the "spec", and thus we just have to adhere to. I really do want to see Float/Double to mean IEEE-float/double. The hardware implementation in x86 is actually IEEE compliant; just not in the expected way. The newer ticket I linked to has an implementation that is both IEEE-compliant and follows what x86 hardware is doing. (MINPS, MAXPS instructions.) I wholeheartedly agree that we need more discussion on all matters relating to floats. In particular (though not relevant in this case), the proper handling of rounding modes, and additional functionality such as fma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 01:53:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 01:53:08 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working Message-ID: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> #10383: AArch64: get GHC Calling convention working -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: aarch64 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building on AArch64 via the LLVM abckend has been working for some time. Its now time to get `("Unregisterised", "NO")` working as well. Enabling GHC calling convention can be done with this patch to `configure.ac`: {{{ diff --git a/configure.ac b/configure.ac index d5d9ab3..a11e5af 100644 --- a/configure.ac +++ b/configure.ac @@ -241,7 +241,7 @@ AC_SUBST(SOLARIS_BROKEN_SHLD) dnl ** Do an unregisterised build? dnl -------------------------------------------------------------- case "$HostArch" in - i386|x86_64|powerpc|arm) + i386|x86_64|powerpc|arm|aarch64) UnregisterisedDefault=NO ;; *) }}} but when building it this way, the stage2 compiler dies will `Illegal instructon`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 03:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 03:08:46 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.534d138468eb5da69b9001022046fcc3@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): I loaded the failing ghc-stage2 command into gdb, set a breakpoint on the `main` function and then single stepped through the assembler. These are the instructions executed: {{{ 0x41b5d8 ldr x4, [x4,#2584] 0x7fb1b44a08 mov x19, x2 0x7fb1b44a0c ldp x10, x11, [x3] 0x7fb1b44a24 str w0, [sp,#108] 0x7fb1b44a24 str w0, [sp,#108] 0x7fb1b44a28 add x0, sp, #0x6c 0x7fb1b44a2c str x1, [sp,#96] 0x7fb1b44a30 add x1, sp, #0x60 0x7fb1b6f080 .inst 0xb1b55488 ; undefined }}} The text of the `MainCapability` function seems to be full of invalid instructions which suggests a linker problem or maybe something going wrong with `TABLES_NEXT_CODE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 03:14:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 03:14:45 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead Message-ID: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template | Version: 7.11 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While I was looking for TH checks which might want to be checked when `Quotes` are enabled ala #10382, I found the "Can't splice the polymorphic local variable" check in `checkCrossStageLifting` in `TcExpr`. I thought this was a bit odd, because there is another implementation of this very function in `RnSplice`. So I went ahead and removed this check from the compiler, and it validated fine. I then went and tried to see if I could tickle the problem. An old mailing list suggested the following test program to induce the error: {{{ module TH_polymorphic where import Language.Haskell.TH import Language.Haskell.TH.Syntax -- See https://mail.haskell.org/pipermail/template- haskell/2006-April/000552.html test2 () = runQ [| foldr f z xs |] where (f,z,xs) = undefined }}} but I get this error: {{{ TH_polymorphic.hs:8:17: error: Could not deduce (Lift t0) arising from a use of ?lift? from the context: Quasi m bound by the inferred type of test2 :: Quasi m => () -> m Exp at TH_polymorphic.hs:(8,1)-(9,30) The type variable ?t0? is ambiguous Note: there are several potential instances: instance (Lift a, Lift b) => Lift (Either a b) -- Defined in ?Language.Haskell.TH.Syntax? instance Lift a => Lift (Maybe a) -- Defined in ?Language.Haskell.TH.Syntax? instance Lift Int16 -- Defined in ?Language.Haskell.TH.Syntax? ...plus 24 others In the expression: lift xs In the first argument of ?runQ?, namely ?[| foldr f z xs |] pending(rn) [, , ]? In the expression: runQ [| foldr f z xs |] pending(rn) [, , ] }}} which seems to be induced the check in `RnSplice`. So is it dead? If so, let's remove it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 03:45:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 03:45:41 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.47744ac4d7e266fcef7c50a8e961a805@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by rwbarton): Well `MainCapability` is a Capability, not a function, so its contents look fine. Of course then there is the question of why we are trying to execute it. In general that assembly trace looks strange, it seems to jump around a few times for no apparent reason. Try adding `+RTS -V0 -RTS` to the failing command line to disable the tick timer, that usually helps when a GHC-built program is acting oddly under gdb, though I don't actually understand this particular weirdness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 07:47:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 07:47:23 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.d5451c6211d30c97948ddb82fb2f24c7@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 08:02:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 08:02:18 -0000 Subject: [GHC] #10372: panic! compiling Y combinator with optimizations In-Reply-To: <042.4bc4d3ef8e2b09a054daf4f8f20341b2@haskell.org> References: <042.4bc4d3ef8e2b09a054daf4f8f20341b2@haskell.org> Message-ID: <057.bdde5462a04c5e7424db50df6d3dc0a0@haskell.org> #10372: panic! compiling Y combinator with optimizations -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.10.1 Resolution: | Keywords: panic, Operating System: Unknown/Multiple | simplifier Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => lowest * milestone: => ? Comment: Yes indeed: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html Alas I know of no good solution, but happily it doesn't seem to bite much (ever?) in real programs. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 08:21:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 08:21:19 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.e184977c820dafa2af940e330046e2f0@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sven Panne [https://mail.haskell.org/pipermail/glasgow-haskell- users/2015-May/025857.html says]: To alleviate the pain a bit, I've uploaded a new version of OpenGLRaw (2.5.0.0) to Hackage, containing 2 improvements: * `foreign import "dynamic"`s with the same signature are re-used, cutting down their number from 3062 to 864. * Those `foreign import "dynamic"`s live in a separate module now. Travis CI seems to be happy with these changes (the VMs there don't have much memory, either), although Haddock still seems to eat memory like hell. But that's a different story... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 08:44:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 08:44:04 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.b8e3471a240f0b2e1e9fb8364f975c4a@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for investigating, Reid. Very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 09:21:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 09:21:45 -0000 Subject: [GHC] #10382: Template Haskell quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.9f20a16fca4db9d3af5c5021745aaca3@haskell.org> #10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure about this. Minor point: we already have a language extension `Opt_QuasiQuotes`. Surely we don't need another! Medium point: this change really only relates to building GHC ''itself'', so it's fairly parochial. For example if we have `[qq| blah |]` in GHC itself, then to compile stage 2 we must have `qq` defined in some library that is compiled with stage 1; a boot library in other words. And the boot libraries are fairly limited. Main thing: It does add complexity. If you write `[qq| blah |]` then: * In stage 1 we must find and dynamically link function `qq`, against the bootstrap compiler * In stage 2 we must find and dynamically link function `qq`, against the stage 1 compiler Moreover, if `HsSyn` has changed, then function `qq` must change too. And if you can manage all this version skew stuff, what's to stop us allowing ''all'' Template Haskell splices in stage 1? I thought it was obvious, but now I can't quite see it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 09:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 09:35:23 -0000 Subject: [GHC] #10385: Annotation restriction is not respected while generating Annotation via TH Message-ID: <046.a42873b06c4b8b607d6d3487710fdc0c@haskell.org> #10385: Annotation restriction is not respected while generating Annotation via TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Magesh B [https://mail.haskell.org/pipermail/ghc-devs/2015-May/008910.html writes]: As per user guide one of the restriction in annotating value is ''the binder being annotated must be declared in the current module''. But when I use TH to generate the annotation above restriction is not respected. Below is the minimal test case to reproduce the issue {{{ ---- Ann.hs {-# LANGUAGE TemplateHaskell #-} module Ann where import Language.Haskell.TH -- {-# Ann id "Orphan Ann for id" #-} -- Rightly produces error "Not in scope: ?id?" $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . return) -- Ideally this should have produced same error as above ---- End of Ann.hs ---- Main.hs {-# LANGUAGE TemplateHaskell #-} module Main where import Ann () import Language.Haskell.TH ann :: [String] ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> [|anns|])) --err = 'a' && True -- Uncomment to introduce compile error main :: IO () main = print ann ---- End of Main.hs }}} Also there is another bug in reifying the Orphan Annotations. In the above example `Main.hs` depends on `Ann.hs` which defines Annotation for `id` When `Main.hs` compiles fine in the first go, its is able to retrieve the annotation for `id` Instead, if `Ann.hs` compiled successfully and `Main.hs` failed to compile and when you later fix the `Main.hs` error, it is not able to retrieve that annotation without recompiling `Ann.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 09:59:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 09:59:43 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.306fbae1edf9ebc982a06ca82b844e69@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I don't think it's dead: * In `RnSplice.checkCrossStageLifting` you'll see that it applies ONLY if the stage is `RnPendingUntyped`, i.e. we are renaming the body of an untyped bracket. It does nothing for typed brackets. So what is happening in `RnSplice` is that we treat `[| ...x...|]` as equivalent to `[| ...(lift x)... |]`, which seems right. But what should happen for ''typed'' splices? Presumably, `[|| ...x....||]` should be equivalent to `[|| ....$(tlift x).... ||]`, where {{{ tlift :: Lift t => t -> TExp t }}} It shouldn't matter if `x` has a polymorphic type, because it'll be instantiated by its context. We might need to whiz up a new `SplicePointName` though. But we don't seem to have `tlift` or anything like it. I'm puzzled. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 10:14:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 10:14:21 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.84dac7e00812af1b1fd3fa3abb794ebf@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This may or may not be related, but Greg Weber [https://mail.haskell.org/pipermail/glasgow-haskell- users/2015-May/025853.html reports]: We have observed issues with compile- time inlining taking much longer in newer versions of GHC in some cases: https://github.com/larskuhtz/toCaseFoldBuildTimes. This particular issue was reported to the text repo: https://github.com/bos/text/issues/116 The former link has a good deal of associated data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 10:15:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 10:15:36 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.5dc7e9ed3b1d9b283b10c4e15b4abf95@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > As reported by Paolo Veronelli: > > Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now > impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB > linux host. The file making memory explode is > Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. > > The file is really huge, but I could compile it with prior versions of > ghc. > > I've had a look and indeed the file takes way more memory to compile with > HEAD. Looking at the heap profiles, it seems that the problem is in GHC > itself (space leak somewhere?). I'll attach the heap profiles (from > compiling the single module itself, i.e., `touch`ing the file and running > prof GHC on it). New description: As reported by Paolo Veronelli: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. I've had a look and indeed the file takes way more memory to compile with HEAD. Looking at the heap profiles, it seems that the problem is in GHC itself (space leak somewhere?). I'll attach the heap profiles (from compiling the single module itself, i.e., `touch`ing the file and running prof GHC on it). Paolo also says: ere is another file , which is small, which cannot be compiled within 4GB memory. https://raw.githubusercontent.com/benl23x5/gloss/master/gloss- examples/raster/Fluid/src-repa/Stage/Linear.hs -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 10:20:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 10:20:49 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.c29327e387944c66738459e13aead5cf@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by simonpj): Is this ARM-specific? I think so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 10:23:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 10:23:52 -0000 Subject: [GHC] #3046: Generalized newtype deriving with associated types In-Reply-To: <053.5760498fe5df42ff01ed60b4c8b401f4@haskell.org> References: <053.5760498fe5df42ff01ed60b4c8b401f4@haskell.org> Message-ID: <068.56a40d5b29db68c8a8f4b700374bc69a@haskell.org> #3046: Generalized newtype deriving with associated types -------------------------------------+------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Correct; #8165 is the relevant ticket, and has a good discussion string. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 11:45:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 11:45:09 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f49f63a5c077e7494e54e115cfcc910c@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Yes, arm specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 11:57:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 11:57:45 -0000 Subject: [GHC] #10235: Get profiling info without stopping program In-Reply-To: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> References: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> Message-ID: <061.79202fdc8a7cc7177a03e9e0afe78e60@haskell.org> #10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kvelicka): I'm currently working on adding such functionality. In the current state of affairs, the problem isn't that the log is not being dumped, it's being written to continuously. The issue is that the release version of `ghc- events` cannot parse incomplete `.eventlog` files. My WIP version of the library does, so if there's a need to profile something urgently, feel free to try it out: https://github.com/kvelicka/ghc-events . Working on this is now a part of my university project, so it should hopefully be finished up and merged into the master branch soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 13:45:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 13:45:50 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.3321f1e2670f13a9d2bd9e30636921ca@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Duplicate of #9557? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 13:55:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 13:55:28 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.ee207d8868787cd93edbcd2874636af3@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8315 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * status: new => closed * resolution: => fixed Comment: Resolved by re-exporting and pushing a new version to hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 14:40:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 14:40:46 -0000 Subject: [GHC] #10382: Template Haskell quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.245dd721dd761db03f8a108da564f5f0@haskell.org> #10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by ezyang): To be clear, I am NOT suggesting quasi-quotes be supported by this; just plain old brackets! (Apologies for the bad names; perhaps "expression quotation" is a more accurate name?) With plain quotes, we don't have to find and link `qq` with this complexity. See the diff that's been attached, which I know works and is not all that complicated. Whether or not the change is parochial, I think it relates to more than just GHC; it applies to any platform where we can compile GHC, but dynamic code loading is not supported (i.e. no GHCi support). Now, you might wonder, "why would anyone need to use TH quotes, without any TH splices?" but Edward Kmett gives an example of one such case, where he wants to put his TH library code (no splices) in a main library, while still supporting platforms without GHCi, without macroing the business. Unusual? Maybe. But someone wants it, and it doesn't seem too hard to give them, so let's do it! If we don't like the language extension, we could alternate make `TemplateHaskell` not immediately error on stage 1 compilation, and just error when we actually reach a splice site. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 14:51:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 14:51:11 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler (was: Template Haskell quotes should work with stage 1 compiler) In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.963b5dfc759894d25d5865dbf1da71d7@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Right now, you must enable the `TemplateHaskell` extension to use quotes, > and `TemplateHaskell` is not supported by the stage 1 compiler. But there > actually is no good reason why this should be the case: quoting doesn't > require any user-written code to be loaded up and run, so it should be > doable by the stage 1 compiler. I propose adding a new extension, > `Quotes`, which turns on JUST quotation and works with the stage 1 > compiler. > > This will solve len's problem https://github.com/ekmett/lens/issues/496 > where they want to rename some syntax using quotation, but don't want > break compilation on a stage 1 compiler. > > See also #10279. New description: Right now, you must enable the `TemplateHaskell` extension to use (non- quasi) quotes, and `TemplateHaskell` is not supported by the stage 1 compiler. But there actually is no good reason why this should be the case: (non-quasi) quoting doesn't require any user-written code to be loaded up and run, so it should be doable by the stage 1 compiler. I propose adding a new extension, `Quotes`, which turns on JUST quotation (NOT quasiquoting) and works with the stage 1 compiler. This will solve len's problem https://github.com/ekmett/lens/issues/496 where they want to rename some syntax using quotation, but don't want break compilation on a stage 1 compiler. See also #10279. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 14:59:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 14:59:57 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.668020b93ca02d2cd4695aa793061058@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: type Resolution: | family, ambiguity check Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9607 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Oleg, is `Arr` injective? If it is then this should by fixed by #6018, which should be merged Real Soon Now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 15:06:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 15:06:13 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.8a43f2c6bc75bc1896b4f256f019a02c@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by ekmett): The current situation: On one hand I have a number of packages that provide `TemplateHaskell` convenience functions for users, `lens` being the go-to example. But on the other hand, I have a bunch of folks who maintain releases for my packages on platforms where only a stage1 compiler is available, Joachim Breitner and the Debian folks used to maintain patches and versions of my code that removed large chunks of the libraries to build on those platforms. When i found out, I offered to support stage1 compilers myself more directly. This ensured a more uniform API, and that different distributions weren't crippling my code in different ways, making it so certain combinators or modules just weren't available on certain platforms. But then we ran into an issue, we needed to generate names that linked to the right places within our code. So we manually construct all of our names ourselves, using the cabal-supplied version number or package key when needed: https://github.com/ekmett/lens/blob/9a247b52ed20e578d9c843d8cc6dad5433a1c186/src/Control/Lens/Internal/TH.hs#L104 Then we just don't use the TemplateHaskell extension ourselves, despite linking against the `template-haskell` package and everything is good enough for us to limp along. I would love to eventually be able to drop this set of hoops, but I have few opinions on the best way to get there. That said, Edward's suggestion of making TemplateHaskell just bomb when you reach a splice site in stage1 rather than immediately would avoid introducing any new flags and sounds pretty simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 15:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 15:27:01 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong Message-ID: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The documentation talks about the flags not enabled by -Wall and then lists the flags enabled by -Wall. Either the negative should be removed or the flags changed to be the ones not implied by -Wall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 16:13:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 16:13:03 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.1133d6107349881cbe0bfbcfc8d9f3ca@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by goldfire): Seems sensible to me, if we just piggyback on the `TemplateHaskell` extension. (I, too, don't like `Quotes`!) If Phab is to be believed that almost all the code changes there are code ''movement'' and not code ''changes'', it does look indeed very simple to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 16:18:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 16:18:40 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.243818f56622f2a1a201dca7b4d05ba0@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by ezyang): I can rewrite the code motion to be added ifdef macros, but it seemed cleaner to just hoist them all out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 16:49:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 16:49:39 -0000 Subject: [GHC] #10235: Get profiling info without stopping program In-Reply-To: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> References: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> Message-ID: <061.2a4cdd77b3418c6e4feb7e292ac078d8@haskell.org> #10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kvelicka): * cc: karolis.velicka@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 17:30:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 17:30:40 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.fa4f2511639f2badffe9ef58b5356203@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Comment: Looking at the Core of: {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances, IncoherentInstances #-} module A where import Language.Haskell.TH.Syntax instance Lift a where lift = undefined x = \y -> [|| y ||] }}} we can see that it goes through `Lift`, and then an `unsafeTExpCoerce`, so there's no need for a separate `tlift` typeclass. (`tcTypedBracket` is responsible for typechecking the expression and then coercing it.) But that was enough of a hint to let me figure out how to tickle this case. {{{ {-# LANGUAGE TemplateHaskell, RankNTypes, ScopedTypeVariables #-} module A where x = \(y :: forall a. a -> a) -> [|| y ||] }}} {{{ A.hs:3:37: Can't splice the polymorphic local variable ?y? In the Template Haskell quotation [|| y ||] In the expression: [|| y ||] In the expression: \ (y :: forall a. a -> a) -> [|| y ||] }}} I'll add a test-case for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 17:35:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 17:35:21 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.b2a320c6d498b4c1f829027b5a694c8e@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"341a76641426a452fc27d3b9383945b9744c600a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="341a76641426a452fc27d3b9383945b9744c600a" Doc: checkCrossStageLifting, RnSplice/TcExpr is untyped/typed brackets (#10384) Clarify that repeated checkCrossStageLifting in RnSplice/TcExpr check untyped/typed brackets, respectively. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 17:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 17:39:56 -0000 Subject: [GHC] #10387: toRational should error out on NaN and Infinity values for Double/Floats Message-ID: <045.440a9786c74d22efa69233e443acd2f2@haskell.org> #10387: toRational should error out on NaN and Infinity values for Double/Floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of `toRational` for `Float`/`Double` types accept `NaN` and `Infinity` values and produce results. For `Infinity` the result nicely maps back to `Infinity`: {{{#!hs Prelude> fromRational (toRational (1/0)) :: Double Infinity Prelude> fromRational (toRational (-1/0)) :: Double -Infinity Prelude> }}} But the same isn't true for NaNs: {{{#!hs Prelude> fromRational (toRational (0/0)) :: Double -Infinity }}} Also, these results are probably architecture specific. In any case, I think `toRational` should simply error out if it receives `NaN` or `Infinity`, as there are really no legitimate values we can map them to, even though we might be able to complete the round-trip correctly in case if infinities. The following just doesn't make sense: {{{#!hs Prelude> toRational (1/0) 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1 }}} So, I propose the `toRational` instance for Float/Double's should simply recognize `NaN` and `Infinite` values and throw an error. [Note that this is also how the HW implementations for the corresponding conversions work, raising a floating-point-exception (in the unmasked case). See `CVTPS2PI`/`CVTPS2DQ` etc., for instance, in x86.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 17:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 17:54:15 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText In-Reply-To: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> References: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> Message-ID: <059.675eac9db959f8cdb050a949abe6015d@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:02:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:02:34 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.151c15dd7d50c23dadb4873f8ee8431c@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:05:08 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.a50ffb7862ad8db221203ca0235725b4@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | Phab:D833,Phab:D836 -------------------------------------+------------------------------------- Changes (by alanz): * differential: Phab:D833 => Phab:D833,Phab:D836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:08:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:08:25 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.f74e2c38e7e0439216eeab1689ba9d7e@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: | Phab:D868,Phab:D836 -------------------------------------+------------------------------------- Changes (by alanz): * differential: Phab:D868 => Phab:D868,Phab:D836 * related: #10315 => #10315,#10354 Comment: Fixing the `HsForAllTy` properly sorts out a number of issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:13:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:13:56 -0000 Subject: [GHC] #10363: ApiAnnotations : HsForAllTy discards parens In-Reply-To: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> References: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> Message-ID: <059.2ff9cfe9c25d770e001f4dd28d0281c6@haskell.org> #10363: ApiAnnotations : HsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: #10315,#10354,#10278 | Blocking: | Differential Revisions: Phab:D836 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D836 * related: => #10315,#10354,#10278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:32:23 -0000 Subject: [GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production In-Reply-To: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> References: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> Message-ID: <059.43378752dbd95110224aed12929455aa@haskell.org> #10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D846 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D846 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 18:33:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 18:33:25 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor In-Reply-To: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> References: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> Message-ID: <064.89048fea2f7e98a0e3e387b0438185fd@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D840 -------------------------------------+------------------------------------- Changes (by alanz): * differential: D840 => Phab:D840 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 20:05:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 20:05:09 -0000 Subject: [GHC] #10388: GHC panic when compiling Yesod app Message-ID: <043.aed19344a06b3eee23932247443b10ff@haskell.org> #10388: GHC panic when compiling Yesod app -------------------------------------+------------------------------------- Reporter: chfi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a Yesod app, using 'yesod devel', GHC crashes with the following error: {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib, 5): Symbol not found: _adverzuGWP0VNzzhgmvBNANratclKO_SubscriptionType_zdfPersistFieldKey_closure Referenced from: /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib Expected in: flat namespace in /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib }}} Specifically, I'm using Yesod's mkPersist to create a data type, and it works fine, until I make said type an instance of FromJSON, in which case the above panic occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 21:12:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 21:12:13 -0000 Subject: [GHC] #10388: GHC panic when compiling Yesod app In-Reply-To: <043.aed19344a06b3eee23932247443b10ff@haskell.org> References: <043.aed19344a06b3eee23932247443b10ff@haskell.org> Message-ID: <058.cb7698a0da8617ec665d1ea2e43229f8@haskell.org> #10388: GHC panic when compiling Yesod app -------------------------------------+------------------------------------- Reporter: chfi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Most likely a duplicate of #10322. If you feel like testing with the patch on that ticket, that would be great, otherwise I'll just assume it is the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 22:16:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 22:16:25 -0000 Subject: [GHC] #10368: STM test failing on Armhf/Linux (was: Armhf/Linux : test T7815 failing) In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.5b638c5373efe5526b1e05c24584e774@haskell.org> #10368: STM test failing on Armhf/Linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #7815 | -------------------------------------+------------------------------------- Description changed by erikd: Old description: > During validation on armhf/linux, I found this test had failed. > > Unfortunately, it only fails intermittently on one quad core Arm board > and not at all on another quad core Arm board. If I do 10 runs of the > test like: > > {{{ > for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo > $? ; done > }}} > > one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 > times. > > The two boards are: > > * Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU. > * Radxa Rock with a Rockchip RK3199 CPU. > > The ifc6540 is the one that fails. New description: During validation on armhf/linux, I found that test T7815 had failed. Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like: {{{ for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo $? ; done }}} one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 times. The two boards are: * Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU. * Radxa Rock with a Rockchip RK3199 CPU. The ifc6540 is the one that fails. @fryguybob suggests that this is actually a bug in the STM implementation that breaks on Arm because of Arm's weaker memory consistency model. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 5 23:48:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 May 2015 23:48:47 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.2c49bdf841fa71d7fd6e3d71d1a0880b@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by axch): Haven't tried. Removing the abstraction in the one problematic place was a sufficient workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 01:15:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 01:15:03 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.e936cd004a9418033a1f1ffb2786b939@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 03:46:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 03:46:11 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.dc81bef103638cc5689bf3d14e3ce408@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by zilinc): I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 07:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 07:26:26 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.4bda1f771087e3bca0e5593a3e11a221@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D849 -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 09:36:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 09:36:26 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.10d9a7aa640722ae4b0475482fe856fd@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: dalaing MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by jstolarek): dalaing, what is the status of your work? I ask because I have a student who would be interested in implementing this ticket but if you are actively working on this ticket we will look for something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 09:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 09:43:56 -0000 Subject: [GHC] #10230: multiline literals doesn't work with CPP extension. In-Reply-To: <045.9376d599c752191abeb407238b734b88@haskell.org> References: <045.9376d599c752191abeb407238b734b88@haskell.org> Message-ID: <060.c0acd745c88fc70cc111b3d8e94769fc@haskell.org> #10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): See also Proposal/NativeCpp which may address this issue to some extent -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 09:44:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 09:44:22 -0000 Subject: [GHC] #10230: multiline literals doesn't work with CPP extension. In-Reply-To: <045.9376d599c752191abeb407238b734b88@haskell.org> References: <045.9376d599c752191abeb407238b734b88@haskell.org> Message-ID: <060.599946ed2db3be9028c04c4b532e5537@haskell.org> #10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 11:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 11:56:26 -0000 Subject: [GHC] #8493: Can't compile happy + ghc with clang's CPP In-Reply-To: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> References: <043.76042121dcfd6c3f0cfaaefb2e590cc6@haskell.org> Message-ID: <058.1c9ca5e4039210874b7a5862d8041708@haskell.org> #8493: Can't compile happy + ghc with clang's CPP -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: happy Resolution: fixed | clang cpp Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: happy clang => happy clang cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 11:57:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 11:57:07 -0000 Subject: [GHC] #8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs In-Reply-To: <045.a0d4b585276ca39919916fbc7191abc1@haskell.org> References: <045.a0d4b585276ca39919916fbc7191abc1@haskell.org> Message-ID: <060.b360ba4b16c76aac712572ded83d48d2@haskell.org> #8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: clang cpp Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: clang => clang cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 11:57:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 11:57:26 -0000 Subject: [GHC] #8444: Fix CPP issue with Xcode5 in integer-simple In-Reply-To: <045.e49e40e4f84743d5cf2dca86128382ee@haskell.org> References: <045.e49e40e4f84743d5cf2dca86128382ee@haskell.org> Message-ID: <060.84909b3b4f680c20cb6ae4cbc36d1727@haskell.org> #8444: Fix CPP issue with Xcode5 in integer-simple -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Keywords: clang cpp Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: clang => clang cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 11:59:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 11:59:25 -0000 Subject: [GHC] #9978: DEBUG is always replaced as 1 when CPP pragma is on In-Reply-To: <046.1e158369b154425aa800b189096e6147@haskell.org> References: <046.1e158369b154425aa800b189096e6147@haskell.org> Message-ID: <061.cf9fbd2a78b3e7ed02de85385810af3a@haskell.org> #9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: cpp Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:00:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:00:00 -0000 Subject: [GHC] #10044: Wrong line number reported with CPP and line beginning with # In-Reply-To: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> References: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> Message-ID: <062.2e629fc1f79bd51a934f641778e9483b@haskell.org> #10044: Wrong line number reported with CPP and line beginning with # -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:34:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:34:13 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.3575c61fccb947ef7bf692acdf5747bb@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Operating System: Linux | Manager, System Time Type of failure: Runtime | Architecture: x86_64 performance bug | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:43:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:43:42 -0000 Subject: [GHC] #10351: Inferred type is rejected In-Reply-To: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> References: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> Message-ID: <061.c9efb9f575473b43bb75ad19d07ba7a6@haskell.org> #10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10351 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): I don't know if this ticket should be re-opened or not, but I do want to note the following. I was compiling the `tasty` package (http://hackage.haskell.org/package/tasty) with `ghc-7.11.20150505` and got the following error: {{{ [11 of 17] Compiling Test.Tasty.Ingredients.ConsoleReporter ( Test/Tasty/Ingredients/ConsoleReporter.hs, dist/dist-sandbox- 4347b07a/build/Test/Tasty/Ingredients/ConsoleReporter.o ) Test/Tasty/Ingredients/ConsoleReporter.hs:124:11: error: Could not deduce (MonadState IntMap.Key f) arising from a use of ?get? from the context: (?colors::Bool, Monoid b) bound by the type signature for: foldTestOutput :: (?colors::Bool, Monoid b) => (IO () -> IO Result -> (Result -> IO ()) -> b) -> (IO () -> b -> b) -> TestOutput -> StatusMap -> b at Test/Tasty/Ingredients/ConsoleReporter.hs:(117,6)-(120,33) or from: Monad f bound by the inferred type of go :: Monad f => TestOutput -> Ap f b at Test/Tasty/Ingredients/ConsoleReporter.hs:(123,3)-(135,18) In a stmt of a 'do' block: ix <- get In the second argument of ?($)?, namely ?do { ix <- get; put $! ix + 1; let statusVar = fromMaybe (error "internal error: index out of bounds") $ IntMap.lookup ix smap readStatusVar = getResultFromTVar statusVar; return $ foldTest printName readStatusVar printResult }? In the expression: Ap $ do { ix <- get; put $! ix + 1; let statusVar = fromMaybe (error "internal error: index out of bounds") $ IntMap.lookup ix smap readStatusVar = getResultFromTVar statusVar; return $ foldTest printName readStatusVar printResult } }}} Where this reported {{{ go :: Mond f => TestOutput -> Ap f b }}} function is defined within a `where` clause. With the behaviour as implemented in the above patch, I first had to annotate `go` in the code as: {{{ go :: MonadState IntMap.Key f => TestOutput -> Ap f b }}} And only then GHC would inform me that I needed to enable `FlexibleContexts`. However, if the behaviour was still as it was as reported in the ticket, pre-patch, GHC would have informed me immediately that I should have enabled `FlexibleContexts`. Or do I misunderstand the intention of the patch? I don't know if it is a bad (and/or common) programming practice to add as many `LANGUAGE` pragma's as GHC tells you to until your code starts compiling. But I know the above patch certainly hinders that practice. Perhaps a separate issue: I don't understand why the `tasty` package compiled on GHC 7.10.1 in the first place, but started failing in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:52:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:52:43 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.3b95e92f743188d17f8fab1a0aaa92a0@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f7daf5afe2ba4f60f60245fa82306b89a272ffa8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f7daf5afe2ba4f60f60245fa82306b89a272ffa8" Normalise type families in the type of an expression Before, the type of an expression, and the type of a variable binding that expression used to be different in GHCi. The reason being that types of bound variables were already normalised. Now, both are normalised. This implements the suggestions as given in Trac #10321 Also adds an expected output for test T10321 Reviewed By: goldfire, simonpj Differential Revision: https://phabricator.haskell.org/D870 GHC Trac Issues: #10321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:52:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:52:43 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.a421cb3de455eb3a820cc4a658b22ae0@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"477f514f6ebcf783810da93e2191e4b6ea65559b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="477f514f6ebcf783810da93e2191e4b6ea65559b" rts: add "-no-rtsopts-suggestions" option Depends on D767 Setting this flag prevents RTS from giving RTS suggestions like "Use `+RTS -Ksize -RTS' to increase it." According to the comment @rwbarton made in #9579, sometimes "+RTS" suggestions don't make sense (e.g. when the program is precompiled and installed through package managers), we can encourage people to distribute binaries with either "-no-rtsopts-suggestions" or "-rtsopts". Reviewed By: erikd, austin Differential Revision: https://phabricator.haskell.org/D809 GHC Trac Issues: #9579 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:58:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:58:13 -0000 Subject: [GHC] #10369: arm binaries have an executable stack In-Reply-To: <044.2b00a277994bcc0061cf34807001386a@haskell.org> References: <044.2b00a277994bcc0061cf34807001386a@haskell.org> Message-ID: <059.910a87aae377092b0c1a0e0b48dc18f7@haskell.org> #10369: arm binaries have an executable stack -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:58:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:58:24 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.ee94a302c8284eafe18756332fdaa1ee@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:58:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:58:38 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.62bd3d5275830ef4c615f6d2a66c7bd0@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 354f5063bac6a91d06f5e37777d594b3140dc668). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 12:59:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 12:59:27 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.2720d4bec319eb43525c00c860a52009@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: => 7.10.2 Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:09:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:09:24 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.b27a16f4a56608f6a37ea8f07c435e2a@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D815 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fb54b2c11cc7f2cfbafa35b6a1819d7443aa5494/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb54b2c11cc7f2cfbafa35b6a1819d7443aa5494" API Annotations : add Locations in hsSyn were layout occurs At the moment ghc-exactprint, which uses the GHC API Annotations to provide a framework for roundtripping Haskell source code with optional AST edits, has to implement a horrible workaround to manage the points where layout needs to be captured. These are MatchGroup HsDo HsCmdDo HsLet LetStmt HsCmdLet GRHSs To provide a more natural representation, the contents subject to layout rules need to be wrapped in a SrcSpan. This commit does this. Trac ticket #10250 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D815 GHC Trac Issues: #10250 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:09:25 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor In-Reply-To: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> References: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> Message-ID: <064.253be30ce8e4f9b40fb5a2fdb208c7cc@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D840 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"caeae1a33e28745b51d952b034e253d3e51e0605/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="caeae1a33e28745b51d952b034e253d3e51e0605" Correct parsing of lifted empty list constructor See #10299 Previously `'[]` was parsed to a `HsTyVar` rather than a `HsExplicitListTy`. This patch fixes the shift-reduce conflict which caused this problem. Reviewed By: alanz, austin Differential Revision: https://phabricator.haskell.org/D840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:09:25 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote In-Reply-To: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> References: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> Message-ID: <059.5a6379c8346c8c103245580bf8e8f633@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D825 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"15aafc7fb61d2cbf95f2a564762399e82fe44e9c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="15aafc7fb61d2cbf95f2a564762399e82fe44e9c" ApiAnnotations : quoted type variables missing leading quote The HsOpTy can be constructed for a promoted type operator, in which case it has the following form | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via the API Annotations. Also, in splice_exp :: { LHsExpr RdrName } : TH_ID_SPLICE { sL1 $1 $ mkHsSpliceE (sL1 $1 $ HsVar (mkUnqual varName (getTH_ID_SPLICE $1))) } | '$(' exp ')' {% ams (sLL $1 $> $ mkHsSpliceE $2) [mo $1,mc $3] } | TH_ID_TY_SPLICE { sL1 $1 $ mkHsSpliceTE (sL1 $1 $ HsVar (mkUnqual varName (getTH_ID_TY_SPLICE $1))) } | '$$(' exp ')' {% ams (sLL $1 $> $ mkHsSpliceTE $2) [mo $1,mc $3] } the TH_ID_SPLICE and TH_ID_TY_SPLICE positions are lost. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D825 GHC Trac Issues: #10268 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:09:25 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.f847a89e845937291e259b305d04f90f@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | Phab:D833,Phab:D836 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"81030ede73c4e3783219b2a8d7463524e847cfce/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="81030ede73c4e3783219b2a8d7463524e847cfce" ApiAnnotations : Nested forall loses forall annotation When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined The parser attaches an AnnForall to the second forall, which appears as a nested HsForAllTy. Somewhere this nesting is flattened, and the tyvarbndrs are collapsed into a single HsForAllTy. In this process the second AnnForAll loses its anchor in the AST. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D833 GHC Trac Issues: #10278 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:30:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:30:20 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.f08fb97a9855aa4671dc22fca2f9b1d7@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 13:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 13:40:28 -0000 Subject: [GHC] #10351: Inferred type is rejected In-Reply-To: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> References: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> Message-ID: <061.fdf4ba6893c599b51f568db5caf08e46@haskell.org> #10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10351 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The difficulty before is that GHC would infer a type ''and then complain that its own inferred type was illegal''. That seems confusing. Moreover sometimes, if it had simply refrained from generalising over that constraint, the program would have been accepted. So the change means that strictly more programs are accepted. But as you discovered, failing to generalise over a constraint may mean that it is reported as unsolved; and only when you fix that does it ask for `FlexibleContexts`. I'm open to suggestions, but the new behaviour seems cleaner to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:31:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:31:18 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.7232d5815a019351d601770075792f73@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by duncan): My suggestion would be that this kind of extra info should go into either the existing generated Paths module, or another generated module. You can do this now with custom code in Setup.hs, but I'm sure we'd welcome a patch to Cabal to make this easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:35:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:35:51 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.0d81ea211ad5619a13043cb493787571@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Changes (by alanz): * differential: Phab:D868,Phab:D836 => Phab:D868 Comment: Phab:D868 is required to be able to handle nested parens in a tuple context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:36:08 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.a4100e6f67a2738474a6ea3393f62e3d@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:38:14 -0000 Subject: [GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place In-Reply-To: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> References: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> Message-ID: <059.4eda7d41ab4fa29bc8a91445370139db@haskell.org> #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D869 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:38:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:38:56 -0000 Subject: [GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. In-Reply-To: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> References: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> Message-ID: <059.a8ec1c5e53f4dd56848993cd81d32ba7@haskell.org> #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D873 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:40:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:40:48 -0000 Subject: [GHC] #10363: ApiAnnotations : HsForAllTy discards parens In-Reply-To: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> References: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> Message-ID: <059.b7da56bec64298a584c4b8d30bc2d3c2@haskell.org> #10363: ApiAnnotations : HsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: #10315,#10354,#10278 | Blocking: | Differential Revisions: Phab:D836 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:42:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:42:33 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.00709068e9d2277d85f1369b35b970eb@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: Phab:D836 | Phab:D868 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * differential: Phab:855,Phab:868 => Phab:D836 Phab:D868 * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 14:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 14:47:10 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.01c54826f92f1aa65fb282cf553d277d@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | thoughtpolice Priority: normal | Status: merge Component: Compiler | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time | Architecture: crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: I'll put this into the 7.10.2 merge queue so that Austin looks at it again -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 16:19:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 16:19:33 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.7fe342fc93f292ce659019cac1a7bf84@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by javran): Replying to [comment:13 bherzog]: > The test-cases are a bit too fragile. All three of the `T9579_stackoverflow_*` tests fail for me because of differences in the reported stack size: > > {{{ > @@ -1,2 +1,2 @@ > -Stack space overflow: current size 99136 bytes. > +Stack space overflow: current size 99208 bytes. > }}} I'll try to fix this, what I have in mind is to pipe stderr to replace the actual number with a constant string, as the actual number is not important for testing this. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 18:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 18:51:23 -0000 Subject: [GHC] #10389: ghc: panic! (the 'impossible' happened) when building "bitmap-0.0.2" Message-ID: <046.fc8b7e571d002500381042600d712197@haskell.org> #10389: ghc: panic! (the 'impossible' happened) when building "bitmap-0.0.2" -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Output from "cabal install bitmap": {{{ Resolving dependencies... Configuring bitmap-0.0.2... Building bitmap-0.0.2... Failed to install bitmap-0.0.2 Build log ( /Users/yairchu/.cabal/logs/bitmap-0.0.2.log ): Configuring bitmap-0.0.2... Building bitmap-0.0.2... Preprocessing library bitmap-0.0.2... [ 1 of 10] Compiling Data.Bitmap.Internal ( Data/Bitmap/Internal.hs, dist/build/Data/Bitmap/Internal.o ) [ 2 of 10] Compiling Data.Bitmap.Base ( Data/Bitmap/Base.hs, dist/build/Data/Bitmap/Base.o ) [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: bitmap-0.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} Reporting this here as suggested by the error message.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 18:57:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 18:57:16 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.4b3e33074b0ba7ce2016c04a77097ce6@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Note that the commit to the `ghc-7.10` branch has a typo. I've opened Phab:D881 to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 6 21:56:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 May 2015 21:56:24 -0000 Subject: [GHC] #10390: Constraint order must match with RankNTypes Message-ID: <047.63f3af47f274c5481e6865e38f17f992@haskell.org> #10390: Constraint order must match with RankNTypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the following code, GHC will not compile unless the constraints on the higher-rank function have the same *order* as the method declaration in `ApPair`. {{{#!hs {-# LANGUAGE RankNTypes #-} class ApPair r where apPair :: (forall a . (ApPair a, Num a) => Maybe a) -> Maybe r instance (ApPair a, ApPair b) => ApPair (a,b) where apPair = apPair' apPair' :: (ApPair b, ApPair c) => (forall a . (ApPair a, Num a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} That is, the following does *not* compile: {{{#!hs apPair' :: (ApPair b, ApPair c) => (forall a . (Num a, ApPair a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} GHC probably shouldn't care about lexical matching when checking constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 00:07:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 00:07:32 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.ec726c44ff057d3a6ad4edb826b61ef6@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by akio): Bryan Buecking has confirmed that the following patch fixes the issue. The patch was taken from the base commit of D849. Strangely I can't find the commit (635619c) in the repository. {{{ diff --git a/libraries/base/GHC/Event/Manager.hs b/libraries/base/GHC/Event/Manager.hs index 11b01ad..cd039b1 100644 --- a/libraries/base/GHC/Event/Manager.hs +++ b/libraries/base/GHC/Event/Manager.hs @@ -456,20 +456,26 @@ onFdEvent mgr fd evs | otherwise = do fdds <- withMVar (callbackTableVar mgr fd) $ \tbl -> - IT.delete (fromIntegral fd) tbl >>= maybe (return []) selectCallbacks + IT.delete (fromIntegral fd) tbl >>= maybe (return []) (selectCallbacks tbl) forM_ fdds $ \(FdData reg _ cb) -> cb reg evs where -- | Here we look through the list of registrations for the fd of interest -- and sort out which match the events that were triggered. We re-arm - -- the fd as appropriate and return this subset. - selectCallbacks :: [FdData] -> IO [FdData] - selectCallbacks fdds = do + -- the fd as appropriate and return a list containing the callbacks + -- that should be invoked. + selectCallbacks :: IntTable [FdData] -> [FdData] -> IO [FdData] + selectCallbacks tbl fdds = do let matches :: FdData -> Bool matches fd' = evs `I.eventIs` I.elEvent (fdEvents fd') - (triggered, saved) = partition matches fdds + (triggered, notTriggered) = partition matches fdds + saved = notTriggered ++ filter (\fd' -> I.elLifetime (fdEvents fd') == MultiShot) triggered savedEls = eventsOf saved allEls = eventsOf fdds + -- Reinsert multishot registrations. + -- We deleted the table entry for this fd above so we there isn't a preexisting entry + IT.insertWith (\_ _-> saved) (fromIntegral fd) saved tbl + case I.elLifetime allEls of -- we previously armed the fd for multiple shots, no need to rearm MultiShot | allEls == savedEls -> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 00:20:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 00:20:42 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.1c9fc78811dbad4faa740aa096da72e8@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): is this related to ticket #10317? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 00:36:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 00:36:10 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.92cc92e0d8543447861780e407faf55f@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D849 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D849 => Phab:D849 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 00:36:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 00:36:25 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.b75443b215bda49b18dda3895032b4db@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D849 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 00:36:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 00:36:42 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.3670d5fff76a3a5b1196a5925ea75bb5@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Yes, this looks like this is a manifestation of #10317 which is fixed by Phab:D849 which unfortunately has yet to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 02:56:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 02:56:16 -0000 Subject: [GHC] #10391: Ability to get contents of TH reified module Message-ID: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> #10391: Ability to get contents of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After using reifyModule, I'd like to be able to inspect the list of exports from that module. At first I thought that this could perhaps be done by changing from {{{#!hs data ModuleInfo = -- | Contains the import list of the module. ModuleInfo [Module] }}} to {{{#!hs data ModuleInfo = -- | Contains the import list and export list of the module. ModuleInfo [Module] [Name] }}} but I now wonder if this is the best plan, because `thisModule >>= reifyModule` might be expected to function as a time machine, allowing us to see declarations that may not have been made yet (in the case where this module's export list is implicit). Can anyone propose a type that would allow us to perform this inspection for modules that have already been baked, but not for "this" module? An intended use case would be in our dimensional types library. We have several modules that define a whole bunch of units. It's useful for the unit name parser to have access to a dictionary with all of those units in it, but maintaining the definition of such a dictionary is redundant. If this feature existed, a module in the parser could import the modules where units are defined, examine the export lists, reify the names in the export lists, determine which represent unit definitions, and emit a declaration of a dictionary that contains them all. (This is in some ways similar to #9699, though perhaps more difficult?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 02:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 02:56:45 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module (was: Ability to get contents of TH reified module) In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.1c909367c097a6d2599b0b47c722c7bd@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 07:55:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 07:55:29 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.a4ad50c4e0ebd6ee2c027884f8601aa6@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 7.12.1 => 7.10.2 Comment: Let's see if we can get the current patch in 7.10.2 (email to ghc-devs on 7/5/15). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 12:41:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 12:41:53 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.c019b8e54b3f3f08d732cc99b8d72787@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I'm not too bothered about the types here: I think it's reasonable just to have a TH-runtime error if someone tries to use a time machine. But what would be a better answer here is an API specification that also addresses #1475, which covers full support for import/export lists. I'd settle for just exports, as imports can be separated quite easily. Unfortunately, I don't have the time to dive into this now, but would be happy to support someone else who did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 15:28:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 15:28:30 -0000 Subject: [GHC] #10392: typo in Debug.Trace.traceShowM example Message-ID: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> #10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- s/traceMShow/traceShowM The documentation for Debug.Trace.traceShowM has an example, where the function is called traceMShow instead of the correct traceShowM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 15:45:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 15:45:29 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.2a7d0a9dee39a106780c0cf471b24c7b@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"931d014d4276d4213d8de4b1f5e51f0219b724dd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="931d014d4276d4213d8de4b1f5e51f0219b724dd" A bit of refactoring RnSplice ...to make clearer what the cross-stage lifting code applies to (c.f. Trac #10384) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 15:45:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 15:45:29 -0000 Subject: [GHC] #10390: Constraint order must match with RankNTypes In-Reply-To: <047.63f3af47f274c5481e6865e38f17f992@haskell.org> References: <047.63f3af47f274c5481e6865e38f17f992@haskell.org> Message-ID: <062.7029777d3d3bb1ad4687cfc6ed954a85@haskell.org> #10390: Constraint order must match with RankNTypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c3e6b3ac50e7cc061825d49d06fb4fc81e6d5bc1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c3e6b3ac50e7cc061825d49d06fb4fc81e6d5bc1" Regression test for Trac #10390 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 16:18:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 16:18:44 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.f6cbfa013ce80b6b3c1c111bd113074e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by dterei): * cc: dterei (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 16:20:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 16:20:02 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.107fac9f35ad27053a82288e2583f0da@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dterei): * cc: dterei (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 16:57:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 16:57:08 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.3e58515d25bbba91bef3ba7c381f7803@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): I'm not sure how strong the connection to #1475 is, because that ticket is about writing new exports in splices, whereas this one is about reading existing splices. I'd like to take a swing at this one, and I've just traced through enough of the code to have a good plan of attack, but I barely even know where to start to tackle #1475, so if you feel strongly that there's something to be gained by attacking both at once then I may not be the man for the job. (Which isn't to say that I won't try, just that I might need considerable help getting up to speed.) Setting aside #1475, on this one the meat of it happens [here](https://github.com/ghc/ghc/blob/4efa421327cf127ebefde59b2eece693e37dc3c6/compiler/typecheck/TcSplice.hs#L1525-L1533): {{{#!hs reifyThisModule = do usages <- fmap (map modToTHMod . moduleEnvKeys . imp_mods) getImports return $ TH.ModuleInfo usages reifyFromIface reifMod = do iface <- loadInterfaceForModule (ptext (sLit "reifying module from TH for") <+> ppr reifMod) reifMod let usages = [modToTHMod m | usage <- mi_usages iface, Just m <- [usageToModule (modulePackageKey reifMod) usage] ] return $ TH.ModuleInfo usages }}} My plan would be to extend the `reifyFromIface` bit to bind the exported names from the `AvailInfo`s in the `mi_exports` field of `iface`, flattening them into a list of names. (I'm not sure quite how to get from `Name.Name` to `Language.TH.Syntax.Name` though...) Then I would add the list of names to the `TH.ModuleInfo`. I would extend the `reifyThisModule` bit to `TH.ModuleInfo usages (error "Accessing the list of names exported by the current module is not supported.")`, or something to that effect. I assume there are style conventions on how to write such errors, I could use a pointer on where to look for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 17:29:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 17:29:49 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.05e3cbba6c101dd26f7d6f8e937f4996@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yes -- I see better how these are decoupled. (I hadn't looked at the API before responding.) Yes, it's reasonable to tackle this separately from #1475. I also didn't realize that you're hooking into existing functions. (I was unaware you could get imports via TH.) It might be worth squawking on ghc- devs (or perhaps libraries at haskell.org) to see if anyone has strong feelings about the API choice. Maybe it's better to deliver imports and exports separately? Maybe have a `Maybe [Name]` for the exports to account for the `thisModule` case? For some reason, I'm OK with a call to a function `reifyThisModule'sExports` to throw an error, but I dislike embedding a call to `error` in an otherwise-proper data structure. Sorry for totally changing my mind on all of these issues, but that's what happens sometimes. :) The implementation plan, from a 30,000 ft view, looks about right. I think `reifyName` is the name conversion function you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 17:31:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 17:31:24 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator In-Reply-To: <047.abf3d61d6edeed38824d04625109fece@haskell.org> References: <047.abf3d61d6edeed38824d04625109fece@haskell.org> Message-ID: <062.1aa496bf47fdef747492154e367babbc@haskell.org> #9863: Provide PowerPC 64 bit native code generator ------------------------------------+------------------------------------ Reporter: trommler | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D629 ------------------------------------+------------------------------------ Comment (by trommler): I have a first attempt at an ELF v2 implementation in my github repository: [https://github.com/trommler/ghc/tree/rebase-May-06]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 19:48:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 19:48:18 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.f58215953f8f84e624ba88595320d4e8@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Just a small update in case anyone is watching. I've mostly got this done. Ended up inlining one of the PCRE bindings since rewriting this without Perl Regex would have ended up in something a lot bigger and complexer. Currently missing the apple-Darwin one implementation and then I'll start cleaning up the code and performing more thorough testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 20:09:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 20:09:19 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.c75536516d84333f235f50ec0033ec79@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Ptharien's Flame): * cc: Ptharien's, Flame (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 20:37:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 20:37:17 -0000 Subject: [GHC] #10389: ghc: panic! (the 'impossible' happened) when building "bitmap-0.0.2" In-Reply-To: <046.fc8b7e571d002500381042600d712197@haskell.org> References: <046.fc8b7e571d002500381042600d712197@haskell.org> Message-ID: <061.934dfbffc975a07a3189ae59dcc3aa11@haskell.org> #10389: ghc: panic! (the 'impossible' happened) when building "bitmap-0.0.2" -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: This looks like a duplicate of #10251, which is fixed in 7.10.2. So I'll close as a duplicate; re-open if I'm wrong. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 20:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 20:37:38 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases In-Reply-To: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> References: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> Message-ID: <061.42a3cbe0a45ea7a5dd043c4ef24789a1@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | deSugar/should_compile/T10251 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): #10389 is another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 21:44:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 21:44:51 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses In-Reply-To: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> References: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> Message-ID: <059.89f25f2e16392d0e3772e3483996bab6@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D832 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"5bde9f7c1834ab4da1fad1838afec1a578c26530/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5bde9f7c1834ab4da1fad1838afec1a578c26530" ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses Summary: The RdrHsSyn.isFunLhs function has the following isFunLhs e = go e [] where go (L loc (HsVar f)) es | not (isRdrDataCon f) = return (Just (L loc f, False, es)) go (L _ (HsApp f e)) es = go f (e:es) go (L _ (HsPar e)) es@(_:_) = go e es The treatment of HsPar means that any parentheses around an infix function will be discarded. e.g. (f =*= g) sa i = f (toF sa i) =^= g (toG sa i) will lose the ( before f and the closing one after g Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D832 GHC Trac Issues: #10269 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 7 22:35:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 May 2015 22:35:53 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.4d0ab7584b4064f989d9ae4964b4a9b9@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D576, | Phab:D585 -------------------------------------+------------------------------------- Changes (by erikd): * status: closed => merge * milestone: 7.12.1 => 7.10.2 Comment: Please merge this patch to `ghc-7.10` branch as it fixes `x86_64/linux` to `armhf/linux` cross compiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 02:01:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 02:01:50 -0000 Subject: [GHC] #10393: Bogus warning with OverloadedLists Message-ID: <047.4f31e76bb02b814e66f057431b9409d9@haskell.org> #10393: Bogus warning with OverloadedLists -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE OverloadedLists #-} lgo :: [a] -> () lgo [] = () lgo (_:_) = () }}} I get {{{ /Users/rae/temp/Bug.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for ?lgo?: Patterns not matched: [] }}} I don't know !OverloadedLists deeply, but that warning surely is confusing! Happens on both 7.8.3 and 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 03:13:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 03:13:03 -0000 Subject: [GHC] #10394: LLVM mangler doesn't mangle AVX instructions Message-ID: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> #10394: LLVM mangler doesn't mangle AVX instructions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The LLVM mangler does not currently transform AVX instructions on x86-64 platforms, due to a missing #include. Also, it is significantly more complicated than necessary, due to the file into sections (not needed anymore), and is sensitive to the details of the whitespace in the assembly. I have attached a modified mangler that I believe to be simpler and more robust. I have not tested it, though, as I do not have a recent enough version of LLVM on my machine. I am marking this as `Runtime crash' because that is what would happen if the unchanged AVX instructions made their way into the executable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 07:37:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 07:37:45 -0000 Subject: [GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection In-Reply-To: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> References: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> Message-ID: <059.624da0cbd195bbca95a05a4326560a53@haskell.org> #10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D834 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"225df19a87d8de8245db84d558618f4824631acc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="225df19a87d8de8245db84d558618f4824631acc" ApiAnnotations : AnnComma missing in TupleSection Summary: For the following code {-# LANGUAGE TupleSections #-} foo = do liftIO $ atomicModifyIORef ciTokens ((,()) . f) the annotation is missing for the comma. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D834 GHC Trac Issues: #10280 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 08:06:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 08:06:14 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.e5a97b2591aef7185fe68b15d5a18596@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: The configure script in both the `master` branch and the `ghc-7.10` branch now explicitly check that the llvm tools are the right versions for the respective branches. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 08:17:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 08:17:31 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt supported llvm version In-Reply-To: <045.3792f024358b600138037f334f93feb4@haskell.org> References: <045.3792f024358b600138037f334f93feb4@haskell.org> Message-ID: <060.20c578dd5e2909255d20e171d04b9a46@haskell.org> #10302: 7.10.1 documenation is incorrect wrt supported llvm version -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: llvm Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by erikd: Old description: > As documented in [#9929] ghc 7.10.1 only supports llvm 3.5. > > This should be documented in the release notes section of the GHC Users's > Guide, Version 7.10.1. > > In addition, the following in the Known bugs section needs to be changed > to mention this also: > > GHC?s LLVM backend is currently incompatible with LLVM 3.4 (issue > #9929). > > The following in section 4.11.2 should also be changed from: > > Currently LLVM 2.8 and later are supported. > > to > > Only LLVM 3.5 is supported. > > from > > Secondly, if you are running Mac OS X with LLVM 3.0 or greater > > to > > Secondly, if you are running Mac OS X with LLVM 3.5 > > from > > In order to use the LLVM based code generator, you should install the > Homebrew package manager for OS X. > > to > > In order to use the LLVM based code generator, you should install the > Homebrew package manager for OS X and then install LLVM 3.5 New description: As documented in #9929 ghc 7.10.1 only supports llvm 3.5. This should be documented in the release notes section of the GHC Users's Guide, Version 7.10.1. In addition, the following in the Known bugs section needs to be changed to mention this also: GHC?s LLVM backend is currently incompatible with LLVM 3.4 (issue #9929). The following in section 4.11.2 should also be changed from: Currently LLVM 2.8 and later are supported. to Only LLVM 3.5 is supported. from Secondly, if you are running Mac OS X with LLVM 3.0 or greater to Secondly, if you are running Mac OS X with LLVM 3.5 from In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X. to In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X and then install LLVM 3.5 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 09:17:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 09:17:35 -0000 Subject: [GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production In-Reply-To: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> References: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> Message-ID: <059.84bbdab96a9eff0e07303abca0d1745d@haskell.org> #10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D846 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"713612674634754edd17264e688f0479d943d8d2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="713612674634754edd17264e688f0479d943d8d2" ApiAnnotations: misplaced AnnComma for squals production Summary: The parser production for squals has : squals ',' transformqual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> ams (sLL $1 $> ()) (fst $ unLoc $3) >> return (sLL $1 $> [sLL $1 $> ((snd $ unLoc $3) (reverse (unLoc $1)))]) } This attaches the comma to the wrong part of the squals, as it is generated in reverse order. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D846 GHC Trac Issues: #10312 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 8 23:18:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 May 2015 23:18:17 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.3cb1fbccea622f8ca06bfb2a9b4f2815@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 02:12:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 02:12:24 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.5f6d74ffe53d7d4887392c719c9399d1@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by angerman): Sorry for being a little late to the discussion. Ideally, I would prefer that a stage1 compiler would try and go ahead with compiling template haskell, until it figures it can't. Motivation being: when ever I find time to hack on out-of-process-template-haskell (effectively trying to bring over luites th approach from ghcjs), I have to inject lots of ifdefs into the ghc code to even get ghc to the point where it starts to complain that it can't compile the splice instead of refusing to even try it right from the start. I haven't had much time to work on it throughout the last half year but would love to continue with it. I'll leave some of the relevant links here: - https://mail.haskell.org/pipermail/ghc-devs/2014-December/007555.html - https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/CrossCompilation From my understanding, and please correct me if I'm wrong, th splices fall into three categories: - (a) IO - can be anything includiing arbitarary IO actions at compile time. - (b) Target dependent - reading target intrinsic values (maxBound :: Int) - (c) everything else that does not include (a) or (b). where (c) should be fine to compile on the host, (b) could probably be also compiled on the host if all the target intrinsic information is taken care of. (a) is going to be interesting, as at least with the out-of- process-th appraoch, you would be running the code on a device that might not have the same environment. Such that thinks like looking up git revisions would have to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 02:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 02:17:14 -0000 Subject: [GHC] #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master Message-ID: <044.aefdd5f5d837c1814bd239fe45388f5b@haskell.org> #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ commit 1a4374c1e246d81a5c1d00a720919804093a8241 Author: Erik de Castro Lopo Date: Mon May 4 23:39:31 2015 +0000 arm: Force non-executable stack (part 2) This was supposed to be part of commit 63a10bbc42 but I pushed from the wrong machine. This fixes cross compiling to arm. }}} Commit `63a10bbc42` has already been cherry-picked to this branch. Without this, cross compiling to arm is broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:25:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:25:10 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.b02eb3b166211551b12632ac9110f3da@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"28257cae77023f2ccc4cc1c0cd1fbbd329947a00/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28257cae77023f2ccc4cc1c0cd1fbbd329947a00" Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. In the following patches, there are: - A few extra safety checks which should be enabled in stage1 - Separation of the th/ testsuite into quotes/ which can be run on stage1 Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:25:11 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.6e33495a33817ef877e6288723a7d8ae@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb" Split off quotes/ from th/ for tests that can be done on stage1 compiler. Signed-off-by: Edward Z. Yang Test Plan: run these tests with stage1 Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D877 GHC Trac Issues: #10382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:25:11 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.c768634c27a8ef2b656e982bedd7713d@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"eb0ed4030374af542c0a459480d32c8d4525e48d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eb0ed4030374af542c0a459480d32c8d4525e48d" RnSplice's staging test should be applied for quotes in stage1. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D878 GHC Trac Issues: #10382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:25:11 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.4019fdb69bdb869005f971dbce30345f@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"9a43b2c1f78b3cf684646af64b9b67dc8079f58f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9a43b2c1f78b3cf684646af64b9b67dc8079f58f" Always do polymorphic typed quote check, c.f. #10384 Summary: Since quotes are enabled in stage1, we need to do the staging check. This also "fixes" #10384 by adding a test for the polymorphic local variable test. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D880 GHC Trac Issues: #10384 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:27:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:27:16 -0000 Subject: [GHC] #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master In-Reply-To: <044.aefdd5f5d837c1814bd239fe45388f5b@haskell.org> References: <044.aefdd5f5d837c1814bd239fe45388f5b@haskell.org> Message-ID: <059.7f82c19cf29d92f16db0993f8fa40f3a@haskell.org> #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:44:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:44:14 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.875b39839c5eeca4432f22187889f6f0@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 08:44:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 08:44:22 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.aa68ec4c4298872e7789ea55337d3411@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 12:22:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 12:22:08 -0000 Subject: [GHC] #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind Message-ID: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the following code fragment {{{#!hs let ls :: Int = undefined }}} the `::` is attached to the `ls` function as a whole, rather than to the pattern on the LHS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 12:23:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 12:23:45 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks Message-ID: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: | Owner: TobyGoodwin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown performance | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: see ticket | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been studying a compiler performance problem in ghc-7.8.4 which is not seen in ghc-7.6.3. Profiling shows the compiler spends 74.3% of its time in `elimCommonBlocks` (in `compiler/cmm/CmmCommonBlockElim.hs`). I came across the problem in real code, and rwbarton on #ghc was able to turn it into a sensible test case, which can be found at http://static.tobold.org/ghc-prof/code/ It's not really a regression, since `elimCommonBlocks` is not enabled by default in 7.6. It can be turned on with `-fnew-codegen`, and that demonstrates a similar slowdown. However 7.8 is worse than 7.6, and 7.10 slightly worse still, for reasons that I haven't explored. Compile times for `RegBig.hs` are: {{{ 7.6.3 -O2 17s 7.6.3 -O2 -fnew-codegen 177s 7.8.4 -O2 230s 7.10.1 -O2 241s }}} The problem obviously stems from the applicative expression with lots of branches `Foo <$> a <*> b <*> c <*> ...` It seems that some level of inlining occurs which means that each extra term in this expression doubles the size of the code. Incidentally, this blowup only occurs when both `RegBig.hs` ''and'' `Form.hs` are compiled with `-O2`. I haven't looked to see why the blowup occurs; although I do see that a similar blowup happens with 7.6. {{{ ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 16,525, types: 31,503, coercions: 73} Result size of Simplifier iteration=2 = {terms: 29,070, types: 45,079, coercions: 73} Result size of Simplifier iteration=3 = {terms: 50,139, types: 62,057, coercions: 73} Result size of Simplifier iteration=4 = {terms: 84,172, types: 83,805, coercions: 73} Result size of Simplifier = {terms: 84,172, types: 83,805, coercions: 73} ... }}} I've looked in some detail at what happens next, tinkering with `elimCommonBlocks` to try to understand why it runs so slowly in this case. There are two major problems. First, `elimCommonBlocks` is worse than O(n^2^), and the inlining blowup mentioned above results in a very large input: 51695 blocks in this example. (Across the project of 50 files or so where this problem originated, I see the input to `elimCommonBlocks` is normally a few hundred blocks at most.) Secondly, there is an effort made in `elimCommonBlocks` to avoid comparing whole blocks all the time, by computing a hash value of some of the block. This fails to produce sufficient unique hash values for this case. The hash must obviously omit the unique block label, and in practice all labels, and various other things, are omitted. In this case, presumably because the code is blown up from the tiny input, many many blocks are similar, and the differences are elided by the hash function. For example, 8177 blocks share the hash value 1094. These 8177 similar blocks all end up in a normal list, which is searched with Data.List.find and the full-block comparison function! Eventually this process concludes that the vast majority are in fact different: for all its hard work, `elimCommonBlocks` only finds about a dozen common blocks in total. Two blocks which both hash to 1094 are these: {{{ cCHc: _se0q::P64 = R1; _c1grM::P64 = _se0q::P64 & 7; if (_c1grM::P64 >= 2) goto c1grR; else goto c1grS; cWK7: _sig3::P64 = R1; _c1iXk::P64 = _sig3::P64 & 7; if (_c1iXk::P64 >= 2) goto c1iXp; else goto c1iXq; }}} I suggest the following steps need to be taken. == 1. Mitigation == Since this is a real problem in the 7.8 and 7.10 series, it needs a simple but effective mitigation. I suggest a test that the input to `elimCommonBlocks` is not "too big", where 1000 seems a reasonable cutoff. Another simple mitigation would be to disable common block elimination altogether (after all, `-O2` is usually understood to mean "make my code go faster even if it gets bigger"). I've tried both these possibilities with 7.8.4. The trivial patches are http://static.tobold.org/ghc-prof/0001-cbe-cutoff.patch and http://static.tobold.org/ghc-prof/0001-no-cbe.patch Compilation times for the test case `RegBig.hs` are as follows, and there is no difference in size in the `.o` file. {{{ 7.8.4 -O2 230s cbe only if input < 1000 blocks 88s no common block elimination 86s }}} == 2. Investigation == I focused on `elimCommonBlocks` thinking that the inline blowup seen earlier in the compilation is reasonable. On reflection, this is probably not so, and I think someone better acquainted with ghc internals should investigate this. == 3. Optimization == `-- TODO: Use optimization fuel` it says in `CmmCommonBlockElim.hs` Since `elimCommonBlocks` is essentially doing a `nub`, it will never perform better than O(n^2^). In fact, it's currently much worse than that as the comparison function changes as duplicate blocks are found, which in turn may create new duplicates, so we have to iterate the nub function till no more dups are found. I did experiment with improving the hash function. It's possible to include target labels, at the expense of needing to recompute block hash values on each iteration. (And currently some ''highly'' ugly code to convert labels to integers.) This considerably reduces the length of some of the hash bucket lists, and so offers a significant speedup: {{{ ghc-7.8.4 -O2 230s "hack" 170s }}} Patch for this is http://static.tobold.org/ghc-prof/0001-cbe-hacks.patch This looks like a promising approach. Including target labels doesn't eliminate all the large hash buckets, so there is scope for further improvements along these lines. I don't see any reason why the hash function should not be as discerning as the equality function, with just occasional accidental clashes. I've also pondered whether more radical rewriting of `elimCommonBlocks` might pay dividends. It's a commonplace that, if you don't need to preserve order, `map head . group . sort` is a faster `nub`. Is the order of blocks significant? I'm not sure - they all seem to end with either `goto` or `call`. I'd ''assume'' that `call` then falls through to the next block but I'm not sure. Anyway, presumably we could `zip [0..]` first, and sort again afterwards, and that should still be asymptotically faster than `nub`. Of course, this presupposes that blocks could be (sensibly? efficiently?) made an instance of `Ord`. (If they were, hash buckets could be stored in an O(1) data structure and binary search employed.) I may be able to find time to pursue some of these avenues, but as a very novice ghc hacker, I'd need some strategic direction here. Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 16:44:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 16:44:43 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.91029a95668cb9089b63b7231d3b665c@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5c459eefcb17ff97beebdc08ccfca21bd8fa5201/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c459eefcb17ff97beebdc08ccfca21bd8fa5201" Revert stage 1 template-haskell. This is a combination of 5 commits. Revert "Quick fix: drop base bound on template-haskell." This reverts commit 3c70ae032e4361b203dfcf22b0a424e8838a5037. Revert "Always do polymorphic typed quote check, c.f. #10384" This reverts commit 9a43b2c1f78b3cf684646af64b9b67dc8079f58f. Revert "RnSplice's staging test should be applied for quotes in stage1." This reverts commit eb0ed4030374af542c0a459480d32c8d4525e48d. Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler." This reverts commit 21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb. Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382." This reverts commit 28257cae77023f2ccc4cc1c0cd1fbbd329947a00. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 16:44:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 16:44:43 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.fe21f93ebb7fc5bd38756cebc569db1b@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5c459eefcb17ff97beebdc08ccfca21bd8fa5201/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c459eefcb17ff97beebdc08ccfca21bd8fa5201" Revert stage 1 template-haskell. This is a combination of 5 commits. Revert "Quick fix: drop base bound on template-haskell." This reverts commit 3c70ae032e4361b203dfcf22b0a424e8838a5037. Revert "Always do polymorphic typed quote check, c.f. #10384" This reverts commit 9a43b2c1f78b3cf684646af64b9b67dc8079f58f. Revert "RnSplice's staging test should be applied for quotes in stage1." This reverts commit eb0ed4030374af542c0a459480d32c8d4525e48d. Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler." This reverts commit 21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb. Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382." This reverts commit 28257cae77023f2ccc4cc1c0cd1fbbd329947a00. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 16:51:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 16:51:00 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.f59f20f27a514c284c45e5eec1aa35f0@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by ezyang): There was a bug: template-haskell needs to build with GHC 7.8, which it does not right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 17:51:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 17:51:17 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.ab3a897471eb9f23f19bd15fe10119f8@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) Comment: @rwbarton Thanks a lot for a smaller use case! I had a brief look at generated Core (for both 7.8.4 and HEAD) and couldn't really find anything suspicious. Also core stats seem similar -- we generate almost identical number of terms/types/coercions. (although I'm far from an expert so take that with a grain of salt) The good news is that I managed to narrow it down to b8392ae76a6d39c57be94b5ba041c450ab479e2b What I did: initially I just wanted to bisect but couldn't really get GHC to build before Jan 2015. So I checkout a commit from early January (the problem is reproducible there) and reverted the above patch (at which point the problem is no longer reproducible). I'll try to look into that commit tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 18:03:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 18:03:09 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.73d2a38e7b96227c6a643dd937a4c6f2@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 9 21:23:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 May 2015 21:23:21 -0000 Subject: [GHC] #10398: Support consecutive named Haddock comments Message-ID: <047.7740b80be062ec1bb48c700ce8a4b3f6@haskell.org> #10398: Support consecutive named Haddock comments -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- (I don't sufficiently understand the manner in which this arises from a GHC issue, but reliable sources inform me that it does.) This haddock issue, https://github.com/haskell/haddock/issues/392, apparently is related to the manner in which GHC parses comments. The way it manifests is that {{{#!hs module Foo ( -- $chunk1 -- $chunk2 foo, -- $chunk3 bar ) where {- $chunk1 This is chunk 1. -} {- $chunk2 This is chunk 2. -} {- $chunk3 This is chunk 3. -} foo = 3 bar = 7 }}} The resulting haddock documentation will include chunks 1 and 3 but not 2. See the linked ticket for a discussion by Mateusz Kowalczyk explaining how this relates to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 08:32:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 08:32:32 -0000 Subject: [GHC] #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind In-Reply-To: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> References: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> Message-ID: <059.3a9d1d4ff189fb1e724a41a6e6cda2c8@haskell.org> #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 16:15:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 16:15:58 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.c4afa5b19565ee9fefccf488110f9fcf@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by alanz): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 16:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 16:40:40 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks Message-ID: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A collection of minor updates for the API Annotations. 1. The annotations for the RdrNames `(+)` and `(-)` are disconnected in the following {{{#!hs import GHC.TypeLits (KnownNat, type (+), type (-)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 17:12:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 17:12:34 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.5173702bf32ebd28a8d2afee16c28d21@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michalt): I'm a bit stuck. I've had a look at that commit, but I don't really understand simplifier well enough to find the reason of the blow-up. Any ideas are welcome! :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 18:02:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 18:02:00 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop Message-ID: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'm writing a toy fractal plotter to teach myself some Haskell. For a while I used GHC 7.4, recently upgraded to 7.10, and found a significant drop in run time performance. Tests with other versions show that the drop dates back to 7.8. Not sure if this is a good practice, or if this is relevant here, but I used bangs to improve performance by adding strictness: this gives a good speedup with 7.4/7.6, but perf is unchanged with 7.8/7.10. || version || run time (sec) - bangs || no bangs || ||7.4.2 || 6.09|| 18.73|| ||7.6.3 || 6.10|| 18.93|| ||7.8.4 || 8.92|| 8.88|| ||7.10.1 || 8.92|| 9.04|| (All builds with ghc -O2.) Source: {{{#!hs {-# LANGUAGE BangPatterns #-} iterations :: Int -> Double -> Double -> Double -> Double -> Int -> Int iterations !maxK !x !y !x0 !y0 !k = let !x2 = x * x !y2 = y * y in if k == maxK || x2 + y2 > 4 then k else iterations maxK (x2 - y2 + x0) (2 * x * y + y0) x0 y0 (k + 1) inSet :: Int -> Int -> (Double, Double) -> Bool inSet !minK !maxK (!x, !y) = k >= minK && k < maxK where !k = iterations maxK x y x y 0 main = do let pointSource = repeat $ ((-0.6518209274278592), 0.3549264214581329) nPoints = 1000 * 1000 points = take nPoints pointSource selected = filter (inSet 1000 (1000 * 20)) points print $ length selected == nPoints }}} The host C compiler is gcc 4.7.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 20:01:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 20:01:22 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.488b2f599325c6e2e9b23b93fd172313@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by alanz: Old description: > A collection of minor updates for the API Annotations. > > 1. The annotations for the RdrNames `(+)` and `(-)` are disconnected in > the following > > {{{#!hs > import GHC.TypeLits (KnownNat, type (+), type (-)) > }}} New description: A collection of minor updates for the API Annotations. 1. The annotations for the implicity parameter is disconnected in the following {{{#!hs type MPI = ?mpi_secret :: MPISecret }}} 2. In the following, the annotation for one of the commas is disconeected. {{{#!hs mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form) }}} 3. In the following, the annotation for the parens becomes disconnected {{{#!hs data MaybeDefault v where SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 20:28:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 20:28:22 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.8f3312df176e6842109aa2f3575dadee@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks! Looks interesting. Have you compared the RTS stats (pass `+RTS -s` to your binary)? Have you compiled your program with profiling enabled, and created a profile (`+RTS -p`), and compared that? Finally, you could compare the produce Core (compile with of `-ddump- simpl`) for obvious differences. Is there a noticable difference whether you use `take n (repeat ..)` or `replicate n ...`? If so, maybe some list fusion is happening or not happening. That should be observable in the RTS stats (number of allocations), or in the Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 21:44:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 21:44:58 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.a6848c6282bb50412cd936835600bda9@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by saffroy): Replying to [comment:1 nomeata]: > Thanks! Looks interesting. Thank you for looking! Below I am comparing 7.6 (last fast version for my use case) to 7.10 (last stable). I have attached various outputs (stats, profiles, cores) for your viewing pleasure. > Have you compared the RTS stats (pass `+RTS -s` to your binary)? Memory usage is considerably smaller with 7.10, though GC times are negligible in both cases. > Have you compiled your program with profiling enabled, and created a profile (`+RTS -p`), and compared that? Profiles look the same. > Finally, you could compare the produce Core (compile with of `-ddump- simpl`) for obvious differences. There are differences in the core loop (''iterations''), but I can't really tell what changed... Can you please have a look? I have attached them. > Is there a noticable difference whether you use `take n (repeat ..)` or `replicate n ...`? If so, maybe some list fusion is happening or not happening. That should be observable in the RTS stats (number of allocations), or in the Core. So I did this: {{{ --- a/ghc_test.hs +++ b/ghc_test.hs @@ -16,6 +16,6 @@ inSet !minK !maxK (!x, !y) = k >= minK & main = do let pointSource = repeat $ ((-0.6518209274278592), 0.3549264214581329) nPoints = 1000 * 1000 - points = take nPoints pointSource + points = replicate nPoints $ head pointSource selected = filter (inSet 1000 (1000 * 20)) points print $ length selected == nPoints }}} With this change, I see no difference in stats or run time. I do see small differences in the core, but for the core loop they seem small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 21:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 21:56:31 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.daabcb1445d508563e1d78b6febcb121@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): @Fuuzetsu: I can reproduce that problem on GHC 7.10.1 but I just built a version of master and can not with that. Does that particular instance of non-determinism look fixed in master to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 10 22:22:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 May 2015 22:22:54 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.900a0090036710d762162c54a2aa0507@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Almost all the time is spent inside `iterations`, which is a 20-instruction long loop in both the 7.6 and 7.8 versions. The two loops are very similar, but some detail causes the 7.8 loop to run about 50% slower, probably some pipeline stall issue. It looks hard to even track down the exact issue, let alone deal with it in the code generator in a general way. I note that the LLVM backend produces a smaller loop which is a bit faster than even the 7.6 loop. The LLVM backend is usually good at optimizing this kind of non-allocating code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 00:41:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 00:41:47 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.b7a4f508725dd4cde5b69fbfbdc7cd45@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by saffroy): Ah! Indeed, with `-fllvm` the run times are much more consistent across versions of GHC. || version || run time (sec) - bangs || no bangs || ||7.4.2 || 4.99|| 19.67|| ||7.6.3 || 4.99|| 19.30|| ||7.8.4 || 4.80|| 4.80|| ||7.10.1 || 4.97|| 4.97|| In this case, do we keep this bug open? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 03:24:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 03:24:59 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.d2df120fc9f23839d616b775a7add517@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * cc: kazu-yamamoto (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 04:25:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 04:25:56 -0000 Subject: [GHC] #10401: state hack-related regression Message-ID: <047.26c3bbc3925b4e36211925d08abc48c0@haskell.org> #10401: state hack-related regression -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program `exp.hs`: {{{ import Control.Monad import Debug.Trace expensive :: String -> String expensive x = trace "$$$" x {-# NOINLINE expensive #-} main :: IO () main = do str <- fmap expensive getLine replicateM_ 3 $ print str }}} When run as `echo hi | ./exp`, it might print either {{{ $$$ "hi" "hi" "hi" }}} or {{{ $$$ "hi" $$$ "hi" $$$ "hi" }}} depending on the compiler version and optimization settings. In 7.8.4, building with `-O2` produces the second (bad) output, while building with `-O2 -fno-state-hack` produces the first output, not surprisingly. However in 7.10.1 and in HEAD both `-O2` and `-O2 -fno-state-hack` produce the second output. It seems this difference in behavior between 7.8.4 and 7.10.1 may be due to the following difference in the unfolding for IO's fmap. In 7.8.4 {{{ ba867929df0910f70431843781ad014d $fFunctorIO2 :: (a -> b) -> GHC.Types.IO a -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: , Unfolding: (\ @ a @ b f :: a -> b x :: GHC.Types.IO a s :: GHC.Prim.State# GHC.Prim.RealWorld -> case x `cast` (GHC.Types.NTCo:IO[0] _R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} while in 7.10.1 {{{ d645bee15151bb50f2bad5912d533b38 $fFunctorIO2 :: (a -> b) -> IO a -> State# RealWorld -> (# State# RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: , Unfolding: InlineRule (3, True, False) (\ @ a @ b f :: a -> b x :: IO a s :: State# RealWorld[OneShot] -> -- ^^^^^^^ case x `cast` (NTCo:IO[0] _R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} I didn't completely confirm this, though, nor determine how that difference arose in the first place (I assume the libraries were built with `-O2` for both versions?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 07:33:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 07:33:30 -0000 Subject: [GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. In-Reply-To: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> References: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> Message-ID: <059.eb26ca5b82174872c4593959d52ffb80@haskell.org> #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D842 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"811b72adedcd12149783eac19ebccff1dd72bc1c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="811b72adedcd12149783eac19ebccff1dd72bc1c" Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. Summary: The code for mkAtDefault is as follows. mkATDefault (L loc (TyFamInstDecl { tfid_eqn = L _ e })) | TyFamEqn { tfe_tycon = tc, tfe_pats = pats, tfe_rhs = rhs } <- e = do { tvs <- checkTyVars (ptext (sLit "default")) equalsDots tc (hswb_cts pats) ; return (L loc (TyFamEqn { tfe_tycon = tc , tfe_pats = tvs , tfe_rhs = rhs })) } An associated type in a class of the form type FoldableConstraint t x = () has an AnnEqual attached to the location in tfid_eqn. Since the location is discarded, this annotation is then disconnected from the AST. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D842 GHC Trac Issues: #10307 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 07:57:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 07:57:22 -0000 Subject: [GHC] #10400: Run time increases by 40% in fractal plotter core loop In-Reply-To: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> References: <046.142ae12f95bb9de430d91e08ef848a7a@haskell.org> Message-ID: <061.9b2d1265bfaf50370703dcbd6b578b6d@haskell.org> #10400: Run time increases by 40% in fractal plotter core loop -------------------------------------+------------------------------------- Reporter: saffroy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: > In this case, do we keep this bug open? Assuming rwbarton?s analysis is correct, I think we can close this bug with a *shrug*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 08:00:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 08:00:38 -0000 Subject: [GHC] #10401: state hack-related regression In-Reply-To: <047.26c3bbc3925b4e36211925d08abc48c0@haskell.org> References: <047.26c3bbc3925b4e36211925d08abc48c0@haskell.org> Message-ID: <062.7dda29292c30cb7e1e6c8c6bcce68737@haskell.org> #10401: state hack-related regression -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The difference you marked is a result of changeset:c001bde73e38904ed161b0b61b240f99a3b6f48d/ghc. But I believe it is not the cause of the problem, as the state hack would, if I understand it correctly, assume `State# RealWorld` to be one-shot independent of whether that annotation is present in the unfolding or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 08:56:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 08:56:29 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy In-Reply-To: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> References: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> Message-ID: <059.9bea4710f94315902569c62eb4b0bb9c@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D848 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"e4032b1951a35d8df63a74ebfee7449988b5ef40/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4032b1951a35d8df63a74ebfee7449988b5ef40" ApiAnnotations : mkGadtDecl discards annotations for HsFunTy Summary: When mkGadtDecl is presented wih a HsFunTy it discards the SrcSpan, thus disconnecting any annotations on the HsFunTy. ``` mkGadtDecl names (L ls (HsForAllTy imp Nothing qvars cxt tau)) = return $ mk_gadt_con names where (details, res_ty) -- See Note [Sorting out the result type] = case tau of L _ (HsFunTy (L l (HsRecTy flds)) res_ty) -> (RecCon (L l flds), res_ty) _other -> (PrefixCon [], tau) ... ``` This can be triggered by the following ``` {-# LANGUAGE GADTs #-} module GADTRecords2 (H1(..)) where -- | h1 data H1 a b where C3 :: (Num a) => { field :: a -- ^ hello docs } -> H1 Int Int ``` Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D848 GHC Trac Issues: #10309 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:27:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:27:00 -0000 Subject: [GHC] #10256: parser: API Annotations : guardquals1 does not annotate commas properly In-Reply-To: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> References: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> Message-ID: <059.6ee8ace2f9713fb023b84c7a9419b2e1@haskell.org> #10256: parser: API Annotations : guardquals1 does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D818 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:27:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:27:29 -0000 Subject: [GHC] #10254: parser : the API annotation on opt_sig is being discarded In-Reply-To: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> References: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> Message-ID: <059.216014ce459ac31efd9c16e1c08d70c3@haskell.org> #10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D822 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:28:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:28:38 -0000 Subject: [GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment In-Reply-To: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> References: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> Message-ID: <059.5f362f010d86d0a38f64b7a473826f2a@haskell.org> #10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D829 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:28:45 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor In-Reply-To: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> References: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> Message-ID: <064.713c8fb155e94af90dc6556cc6d982ec@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D840 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:29:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:29:22 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote In-Reply-To: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> References: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> Message-ID: <059.777fcad6ede889eae391369250195986@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D825 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:29:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:29:41 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses In-Reply-To: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> References: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> Message-ID: <059.17f864263cb27d7199be68e93a31ddd3@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D832 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:30:04 -0000 Subject: [GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection In-Reply-To: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> References: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> Message-ID: <059.4bde3ea8581adde679f454d7e6ab4095@haskell.org> #10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D834 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:31:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:31:06 -0000 Subject: [GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production In-Reply-To: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> References: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> Message-ID: <059.bf86a83fa715de056e083c65821679a5@haskell.org> #10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D846 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:38:58 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.f934a1bafd48c66bb8993835b183588c@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 09:43:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 09:43:01 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.9f3e47f959e024aa3f8c2daeaec47cf7@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:06:30 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.03ab9f44930d1668c9a798f37d536763@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10109 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: This was actually merged a while back; just not closed (see d5c089208735014a09d43b1ee757f52ddbfc92bf). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:08 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.e60b450085c6c7b87bf2159607e2ebe8@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:17 -0000 Subject: [GHC] #10285: Bug in Coerciible In-Reply-To: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> References: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> Message-ID: <061.0dcc4e851d5d3a2c2fa0adfb680ec45e@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10285 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:21 -0000 Subject: [GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling In-Reply-To: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> References: <044.a3f80c6c0a5d3377f5d023665058edc9@haskell.org> Message-ID: <059.38e5a707ba9bd0ed520ecf10ed2340a6@haskell.org> #9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D576, | Phab:D585 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:31 -0000 Subject: [GHC] #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master In-Reply-To: <044.aefdd5f5d837c1814bd239fe45388f5b@haskell.org> References: <044.aefdd5f5d837c1814bd239fe45388f5b@haskell.org> Message-ID: <059.a5bc9b319b3fc7e0ba439b97cab4d921@haskell.org> #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:33 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.0ea6967ddc27ceda2cbd276aa07edbd1@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | roles/should_compile/T10263 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:08:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:08:56 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.98d69234f63b7dd7e59d7c545b969265@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | roles/should_compile/T10263 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:12:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:12:42 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.29e06ed6794c724c0872fa48d4d23c9d@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:13:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:13:16 -0000 Subject: [GHC] #10210: Documentation link to 7.10.1 migration guide broken In-Reply-To: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> References: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> Message-ID: <067.7fec066bbc1b2aac3b6b5a8b1d7ab948@haskell.org> #10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: Documentation | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Alright, fixed by 8ae3768b3185db307fb911dda83e84f440bd048e - although I will need to regenerate the docs, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:14:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:14:30 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.7d59abf5a4fd020a26f6e105988c4cf2@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Edward, I'm confused. The ticket is closed, but all patches seem to have been reverted. What's up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:37:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:37:44 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.f56fc61714f98349b6304e36e4002b97@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: type Resolution: | family, ambiguity check Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9607 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oleg): Well, Arr is a function of three arguments. For a particular choice R for the first argument, Arr R is a->b and hence injective, but one may well define Arr R' a b = String, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:52:26 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.b5e3394bcf219ec8b67d19b4dd0e9e92@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.12.1 Comment: (Moving to 7.12.1, as lack of updates means this is unlikely to be slated for 7.10.2) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:55:43 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.1b5d132da02f123039f987436dbfd4f1@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Mateusz [https://mail.haskell.org/pipermail/ghc-devs/2015-May/008992.html says]: I'd like to bring some attention to ticket #4012 about non- determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. The situation was pretty bad in 7.8.4 in presence of parallel builds so we switched those off. Joachim's a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and we were hopeful for 7.10. Now that 7.10.1 is out and people have been using and testing it, the situation turns out to be really bad: daily we get multiple reports from people about their packages ending up broken and our only advice is to do what we did back in 7.8 days which is to purge GHC and rebuild everything locally or fetch everything from a machine that already built it all, as long as the two don't mix. This is not really acceptable. See comment:76 on #4012 for an example of a rather simple file you can compile right now with nothing extra but -O and get different interface hash. This e-mail is just to raise awareness that there is a serious problem. If people are thinking about cutting 7.10.2 or whatever, I would consider part of this ticket to be a blocker as it makes using GHC reliably while benefitting from binary caches pretty much impossible. Of course there's the ?why don't you fix it yourself? question. I certainly plan to but do not have time for a couple more weeks to do so. For all I know right now, the fix to comment:76 might be easy and someone looking for something to hack on might have the time to get to it before I do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:56:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:56:20 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.eadf2eaf6268e543f16419ea80812da1@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for bringing this up Mateusz. The ticket description lists four sources of non-deterministic outputs. I think you are saying that 7.10.1 has a fifth (as yet uncharacterised) source, which somehow bites more often than the preceding four. Is that right? Is comment:76 the single exemplar of the difficulty, or are there others? Mateusz says that we should not release 7.10 until comment:76 is fixed. Do others agree? Does anyone feel able to characterise what is going on with comment:76? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 10:57:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 10:57:30 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.a511702d8636d33f47f6aad71f5bd7e2@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > There are some issues with non-determinism in the output of GHC, which > means that compilations are not repeatable. This affects some users > (e.g. Debian packagers) who need to be able to get repeatable hashes for > the packages of a GHC build. > > The cases we know about that lead to non-deterministic results are: > > * The `spec_ids` (specialised Ids) attached to an Id have a non- > deterministic ordering > * CSE can give different results depending on the order in which the > bindings are considered, and since the ordering is non-deterministic, the > result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, > where `y` and `x` are exported, we can end up with either `x = y; y = 3` > or `y = x; x = 3`. > * There seems to be something unpredictable about the order of arguments > to SpecConstr-generated specialisations, see > [http://www.haskell.org/pipermail/glasgow-haskell- > users/2011-April/020287.html] > * The wrappers generated by the `CApiFFI` extension have non- > deterministic names. (see comment:15 below). > > '''Old ticket description follows''' > > Short story: if you use ghc-6.12.1.20100318 (or similar, probably > ghc-6.12.1 release will produce the same results) to bootstrap > ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, > those two instances of ghc-6.12 will have different ABI hashes and > interfaces in the ghc package. If you use ghc-6.10 for the > bootstrapping, you'll even get differences in the ghc, base and > Cabal packages. > > Long story: see logfiles and descriptions at http://darcs.volkswurst.de > /boot-tests/ (note that the logfiles are quite large, I really don't want > to attach 150 MB of logs to this ticket). New description: There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable. This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build. The cases we know about that lead to non-deterministic results are: * The `spec_ids` (specialised Ids) attached to an Id have a non- deterministic ordering * CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`. * There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell- users/2011-April/020287.html] * The wrappers generated by the `CApiFFI` extension have non- deterministic names. (see comment:15 below). * See comment:76 for another, different, example '''Old ticket description follows''' Short story: if you use ghc-6.12.1.20100318 (or similar, probably ghc-6.12.1 release will produce the same results) to bootstrap ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, those two instances of ghc-6.12 will have different ABI hashes and interfaces in the ghc package. If you use ghc-6.10 for the bootstrapping, you'll even get differences in the ghc, base and Cabal packages. Long story: see logfiles and descriptions at http://darcs.volkswurst.de /boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 11:00:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 11:00:24 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt supported llvm version In-Reply-To: <045.3792f024358b600138037f334f93feb4@haskell.org> References: <045.3792f024358b600138037f334f93feb4@haskell.org> Message-ID: <060.de7c4c1864575071c23e68587b9f4cd9@haskell.org> #10302: 7.10.1 documenation is incorrect wrt supported llvm version -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Documentation | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: llvm Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Fixed by 1915e7f3ab4b801bec5557709a18368c20b0036d. This is only in `ghc-7.10` because this will all need to change for GHC 7.12 if [wiki:ImprovedLLVMBackend] fully goes through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 11:31:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 11:31:43 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" In-Reply-To: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> References: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> Message-ID: <057.52947ad23c1e1f807c1f93329f39327d@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | thoughtpolice Priority: highest | Status: upstream Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Documentation | Architecture: bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2666ba369f8d3e7d187876b7b602d42f2d6db381/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2666ba369f8d3e7d187876b7b602d42f2d6db381" haddock: update submodule to fix #10206 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 11:37:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 11:37:03 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" In-Reply-To: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> References: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> Message-ID: <057.7571fd77e83f1a5a477c59dfab07cc5e@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | thoughtpolice Priority: highest | Status: closed Component: Documentation | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Documentation | Architecture: bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: upstream => closed * resolution: => fixed Comment: OK, upstream fix merged into `ghc-head/master` on the haddock repository, and merged into `master/ghc-7.10` for us. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 11:47:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 11:47:45 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.a2f60b8f497786eba827deaaeeb5ea0b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Alright, all four of these commits are now merged to `ghc-7.10` - thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 12:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 12:00:59 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.f06820534118af4893e7a3afa40a67aa@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: Compiler | Milestone: 7.12.1 Resolution: fixed | Version: 7.10.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time | Architecture: crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: I looked at it again, and I'm still inclined to leave it out. :) It would be possible to remove the bits from the redundant superclass warning patch that touch it, but it looks like there have been some other various changes resulting in quite a few hunks that don't match up. So, unless someone Really Really needs it (or would like to backport the patch themselves!), I'd prefer to keep this one pointed to 7.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 12:03:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 12:03:45 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.03411928b1e11f4d520d62e47d3953a2@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- Blocked By: | types/should_compile/T9840 Related Tickets: #8028 | Blocking: | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by thoughtpolice): So, this one visibly changes the API and requires a Haddock update, so I'm pretty inclined to leave it as is and not merge. Adam, is this one critical, or can it be worked around/backported reasonably? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 12:05:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 12:05:58 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.c60eb4da428498264c1820455c6c5e77@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- Blocked By: | types/should_compile/T9840 Related Tickets: #8028 | Blocking: | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: merge => closed * resolution: => fixed * milestone: => 7.12.1 Comment: On reflection, I agree, let's leave this in HEAD but not merge into 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 12:13:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 12:13:51 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.a90ba1ed3d15dc3b528043d4ebe91f71@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9736c042f4292b4fb94ca9faca6a010372a0f92f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9736c042f4292b4fb94ca9faca6a010372a0f92f" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 12:18:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 12:18:19 -0000 Subject: [GHC] #10287: ApiAnnotations : BooleanFormula construction discards original In-Reply-To: <044.dc10540293e80736094df33a8e676e4d@haskell.org> References: <044.dc10540293e80736094df33a8e676e4d@haskell.org> Message-ID: <059.035d578a9c241c5889342c0f8e6eac63@haskell.org> #10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D837 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"24707d72d6137cb970878ef243c090a6bf6601e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="24707d72d6137cb970878ef243c090a6bf6601e0" ApiAnnotations : BooleanFormula construction discards original Summary: The MINIMAL pragma is captured in the parser using a BooleanFormula. The constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the boolean formula as it is constructed. This discards the original information, making round tripping impossible. Note: there is another version which provides a more API Annotations friendly version of the MINIMAL pragma, but this requires changes to haddock, which will cause problems for 7.10.2. See https://github.com/alanz/ghc/tree/wip/10287 Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, Fuuzetsu, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D837 GHC Trac Issues: #10287 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 13:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 13:24:31 -0000 Subject: [GHC] #10401: state hack-related regression In-Reply-To: <047.26c3bbc3925b4e36211925d08abc48c0@haskell.org> References: <047.26c3bbc3925b4e36211925d08abc48c0@haskell.org> Message-ID: <062.ba79b548180debbb8ef5204788effd6b@haskell.org> #10401: state hack-related regression -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): But the ticket is mostly about the behavior of 7.10.1 with `-O2 -fno- state-hack`. Does that change things? (Probably should have been clearer about this.) In 7.8 we have `-fno-state-hack` as an escape hatch for when the state hack heuristic goes wrong. But we can't expect people to rebuild all their dependencies including `base` with `-fno-state-hack`, and disabling optimizations completely is not very satisfactory either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 13:27:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 13:27:59 -0000 Subject: [GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place In-Reply-To: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> References: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> Message-ID: <059.462254c1612910a999821c9a2bb89c80@haskell.org> #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D869 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"fe38195eb783fc2f2f2d5ef50fb665b06fd15e82/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe38195eb783fc2f2f2d5ef50fb665b06fd15e82" ApiAnnotations : pquals production adds AnnVbar in the wrong place Summary: The Parser.y production for pquals is pquals :: { Located [[LStmt RdrName (LHsExpr RdrName)]] } : squals '|' pquals {% addAnnotation (gl $ last $ unLoc $1) AnnVbar (gl $2) >> return (sLL $1 $> (reverse (unLoc $1) : unLoc $3)) } | squals { L (getLoc $1) [reverse (unLoc $1)] } The squals are returned in reverse order, so the AnnVbar should be attached to the head of the list, not the last. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D869 GHC Trac Issues: #10357 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 14:09:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 14:09:39 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.96fff4a5106c4e2108fee90296c89906@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: type Resolution: | family, ambiguity check Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9607 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): > one may well define Arr R' a b = String But the question is whether `Arr R' a b = String` is an acceptable definition? If yes, then of course injectivity is not a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 14:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 14:18:32 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 Message-ID: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: powerpc | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Building some Debian packages on powerpc with GHC 7.8.4 fails as shown in this [https://buildd.debian.org/status/fetch.php?pkg=haskell-wai-app- static&arch=powerpc&ver=3.0.1-3&stamp=1431236338 build log], e.g.: {{{ ghc: /usr/lib/haskell-packages/ghc/lib/powerpc-linux-ghc-7.8.4/unix- time-0.3.5/libHSunix-time-0.3.5.a: unhandled ELF relocation(RelA) type 252 }}} I'm no PPC ABI expert, but I think the attached patch against master (which applies equally to 7.8.4) is reasonably plausible, and it at least allows wai-app-static to build cleanly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 14:21:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 14:21:09 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.134fdbe99a446c924f1b83078509cd91@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by cjwatson): Apologies for attaching a vim swap file by mistake the first time round! Feel free to delete that if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:03:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:03:55 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.38d3d69298aaa2bc9e9f0a6d72be7562@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by rwbarton): Looks plausible to me too. Do we assume these new relocation types are a result of a new version of binutils? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:15:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:15:01 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.ed2a988321319661c842c78b6754382d@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: ezyang => * status: closed => new * resolution: fixed => Comment: I think Edward said in IRC that the template-haskell library needs to be fixed up to build with 7.8 again first, since the commits in this ticket cause it to be built as a boot library and we need to be able to bootstrap with 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:15:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:15:13 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.dc4b85b7d539ad86d068f7467ba4b83a@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:17:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:17:25 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.d390e862e49d77ed3512bad4b40aa6b4@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:23:05 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.4ba13b2ea9302d37b1d685fcf8996c4a@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by cjwatson): I'm not at all sure; it seems like the obvious candidate, but I don't know enough to be able to search the enormous haystack of changelogs for this particular needle. I figured that GHC generally took the approach here of just implementing whichever relocations happened to be needed (the only additional ones I actually saw directly were R_PPC_REL16_HA and R_PPC_PLTREL24, in fact, but the other two were trivial to do at the same time). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:24:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:24:09 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.f65ee3639039ca751cb84fb6eb52bdb5@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:19 zilinc]: > I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? I also share the same feeling and sorry for being late to comment here. This is quite a common pattern out there. Removing versionTags to avoid the Eq/Ord inconsistency seems like the easiest approach but not the best one, imho. Why not stick to semver.org: MAJOR.MINOR.PATCH(-PRERELEASE)?(+tag)*, where: * "Pre-release versions have a lower precedence than the associated normal version" * "Build metadata SHOULD be ignored when determining version precedence" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:27:48 -0000 Subject: [GHC] #10366: Post link to MacOS binary of 7.10 In-Reply-To: <047.96813fefee3197627308f4e0ad81012c@haskell.org> References: <047.96813fefee3197627308f4e0ad81012c@haskell.org> Message-ID: <062.ea93d9daaf543796623063ee254def95@haskell.org> #10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | thoughtpolice Priority: highest | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:28:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:28:50 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.c84ca3f92f9347df2a6ee1d86c353b17@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: #8977 => #8977, #10298 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:31:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:31:59 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.cfda1fa40c4460b9dec92d18512c035c@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Originally discussed at: https://groups.google.com/d/msg/haskell- > cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as > a static linking and Docker issue, but in fact affects dynamically linked > executables without any containerization. > > I've put together the following script that reproduces my problem: > > {{{ > cat > hello.hs < main :: IO () > main = putStrLn "Hello World" > EOF > ghc hello.hs > > rm -rf tmp > mkdir tmp > > cp hello tmp > > mkdir -p tmp/usr/lib/x86_64-linux-gnu > cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu > > mkdir -p tmp/lib/x86_64-linux-gnu > cp \ > /lib/x86_64-linux-gnu/libm.so.6 \ > /lib/x86_64-linux-gnu/librt.so.1 \ > /lib/x86_64-linux-gnu/libdl.so.2 \ > /lib/x86_64-linux-gnu/libc.so.6 \ > /lib/x86_64-linux-gnu/libpthread.so.0 \ > tmp/lib/x86_64-linux-gnu > > mkdir -p tmp/lib64 > cp /lib64/ld-linux-x86-64.so.2 tmp/lib64 > > #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/ > #cp \ > # /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \ > # /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \ > # tmp/usr/lib/x86_64-linux-gnu/gconv > > sudo chroot tmp /hello > }}} > > If I uncomment the block that copies the gconv files, the program runs as > expected. However, without those files copied, the program burns CPU and > consumes memory until killed by the OS. I ran strace on a similar > executable, and got the results at: > > https://gist.github.com/snoyberg/095efb17e36acc1d6360 > > Note that this problem also occurs with statically linked executables > when some of the other dynamically linked libraries are not available in > the chroot environment. > > Expected behavior: ideal would be not to require the gconv files and > other shared libraries be present, especially when statically linked. > Barring that, it would be much better if the RTS could produce a > meaningful error message about the missing file. Note that strace does > demonstrate that a open system call is failing, e.g.: > > open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = > -1 ENOENT (No such file or directory) > > Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit. New description: Originally discussed at: https://groups.google.com/d/msg/haskell- cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as a static linking and Docker issue, but in fact affects dynamically linked executables without any containerization. Other examples of the same bug: #7695, #8977, #8928 I've put together the following script that reproduces my problem: {{{ cat > hello.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:32:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:32:11 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.1f510b9d1a5236de533e66813477b0ad@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > Originally discussed at: https://groups.google.com/d/msg/haskell- > cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as > a static linking and Docker issue, but in fact affects dynamically linked > executables without any containerization. > > Other examples of the same bug: #7695, #8977, #8928 > > I've put together the following script that reproduces my problem: > > {{{ > cat > hello.hs < main :: IO () > main = putStrLn "Hello World" > EOF > ghc hello.hs > > rm -rf tmp > mkdir tmp > > cp hello tmp > > mkdir -p tmp/usr/lib/x86_64-linux-gnu > cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu > > mkdir -p tmp/lib/x86_64-linux-gnu > cp \ > /lib/x86_64-linux-gnu/libm.so.6 \ > /lib/x86_64-linux-gnu/librt.so.1 \ > /lib/x86_64-linux-gnu/libdl.so.2 \ > /lib/x86_64-linux-gnu/libc.so.6 \ > /lib/x86_64-linux-gnu/libpthread.so.0 \ > tmp/lib/x86_64-linux-gnu > > mkdir -p tmp/lib64 > cp /lib64/ld-linux-x86-64.so.2 tmp/lib64 > > #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/ > #cp \ > # /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \ > # /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \ > # tmp/usr/lib/x86_64-linux-gnu/gconv > > sudo chroot tmp /hello > }}} > > If I uncomment the block that copies the gconv files, the program runs as > expected. However, without those files copied, the program burns CPU and > consumes memory until killed by the OS. I ran strace on a similar > executable, and got the results at: > > https://gist.github.com/snoyberg/095efb17e36acc1d6360 > > Note that this problem also occurs with statically linked executables > when some of the other dynamically linked libraries are not available in > the chroot environment. > > Expected behavior: ideal would be not to require the gconv files and > other shared libraries be present, especially when statically linked. > Barring that, it would be much better if the RTS could produce a > meaningful error message about the missing file. Note that strace does > demonstrate that a open system call is failing, e.g.: > > open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = > -1 ENOENT (No such file or directory) > > Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit. New description: Originally discussed at: https://groups.google.com/d/msg/haskell- cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as a static linking and Docker issue, but in fact affects dynamically linked executables without any containerization. I've put together the following script that reproduces my problem: {{{ cat > hello.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:32:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:32:50 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.c0405189497de68930779ebb802bed65@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > Originally discussed at: https://groups.google.com/d/msg/haskell- > cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as > a static linking and Docker issue, but in fact affects dynamically linked > executables without any containerization. > > I've put together the following script that reproduces my problem: > > {{{ > cat > hello.hs < main :: IO () > main = putStrLn "Hello World" > EOF > ghc hello.hs > > rm -rf tmp > mkdir tmp > > cp hello tmp > > mkdir -p tmp/usr/lib/x86_64-linux-gnu > cp /usr/lib/x86_64-linux-gnu/libgmp.so.10 tmp/usr/lib/x86_64-linux-gnu > > mkdir -p tmp/lib/x86_64-linux-gnu > cp \ > /lib/x86_64-linux-gnu/libm.so.6 \ > /lib/x86_64-linux-gnu/librt.so.1 \ > /lib/x86_64-linux-gnu/libdl.so.2 \ > /lib/x86_64-linux-gnu/libc.so.6 \ > /lib/x86_64-linux-gnu/libpthread.so.0 \ > tmp/lib/x86_64-linux-gnu > > mkdir -p tmp/lib64 > cp /lib64/ld-linux-x86-64.so.2 tmp/lib64 > > #mkdir -p tmp/usr/lib/x86_64-linux-gnu/gconv/ > #cp \ > # /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so \ > # /usr/lib/x86_64-linux-gnu/gconv/gconv-modules \ > # tmp/usr/lib/x86_64-linux-gnu/gconv > > sudo chroot tmp /hello > }}} > > If I uncomment the block that copies the gconv files, the program runs as > expected. However, without those files copied, the program burns CPU and > consumes memory until killed by the OS. I ran strace on a similar > executable, and got the results at: > > https://gist.github.com/snoyberg/095efb17e36acc1d6360 > > Note that this problem also occurs with statically linked executables > when some of the other dynamically linked libraries are not available in > the chroot environment. > > Expected behavior: ideal would be not to require the gconv files and > other shared libraries be present, especially when statically linked. > Barring that, it would be much better if the RTS could produce a > meaningful error message about the missing file. Note that strace does > demonstrate that a open system call is failing, e.g.: > > open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = > -1 ENOENT (No such file or directory) > > Reproduced on GHC 7.8.4 and 7.10.1, on Ubuntu 14.04 64-bit. New description: Originally discussed at: https://groups.google.com/d/msg/haskell- cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as a static linking and Docker issue, but in fact affects dynamically linked executables without any containerization. Other examples of the same bug: #7695, #8977, #8928 I've put together the following script that reproduces my problem: {{{ cat > hello.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:33:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:33:22 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.ae93e13dbbf31617b988565a9ee1d78c@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Oh, also, we should definitely have a `Note` explaining exactly what's going on here, just in case we change it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:34:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:34:43 -0000 Subject: [GHC] #10394: LLVM mangler doesn't mangle AVX instructions In-Reply-To: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> References: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> Message-ID: <062.06de98a9d74cbc98ce34239c7fa3988f@haskell.org> #10394: LLVM mangler doesn't mangle AVX instructions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: bgamari (added) Comment: In fact the CPP around the AVX rewriting stuff was broken anyways (should have been `#ifdef REWRITE_AVX` not `#if REWRITE_AVX`) so even if `x86_64_TARGET_ARCH` was set, the result would have been a CPP error. It looks like this never actually worked. Makes me wonder if we even need the AVX rewriting nowadays; or maybe we've told LLVM not to use these instructions, and could now allow it to; or maybe we can tell it not to assume the stack is 32-byte aligned. Your rewrite looks generally sensible, though I haven't examined it closely. cc'ing Ben since I think he did the conversion to use prefix data for tables-next-to-code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:50:22 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.b817950d34fa74d5268510f54b08493f@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The return/pure thing presumably arises because we have `return = pure`, or vice versa, and one is "shorted out" in favour of the other. See `SimplCore.shortOutIndirections`. Would someone like to see if this is true? If someone cares to confirm this, then perhaps `shortOutIndirections` could choose whether to elminate `return` or eliminate `pure` based on a lexicographic comparison of their names? Would someone like to see if this would work? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 15:56:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 15:56:08 -0000 Subject: [GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. In-Reply-To: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> References: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> Message-ID: <059.c55e3ea430f4a0a5b8b996c602bd4fa6@haskell.org> #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D873 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"ecc3d6be218b1c7a36ee3f2f36c4f3ac4f45c34f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ecc3d6be218b1c7a36ee3f2f36c4f3ac4f45c34f" ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. Summary: The production for decl_no_th starts decl_no_th :: { Located (OrdList (LHsDecl RdrName)) } : sigdecl { $1 } | '!' aexp rhs {% do { let { e = sLL $1 $> (SectionR (sL1 $1 (HsVar bang_RDR)) $2) }; pat <- checkPattern empty e; ... The e value should be just the pattern, excluding the rhs, but the span created includes the rhs. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D873 GHC Trac Issues: #10358 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:05:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:05:33 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature Message-ID: <051.3964e20a20585ae510669b50854eeffc@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code crashes GHC 7.10.1 as is, but doesn't result in a crash if the signature is specified completely or isn't specified at all (inferred): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} module Main where data I a = I a instance Functor I where fmap f (I a) = I (f a) newtype B t a = B a instance Functor (B t) where fmap f (B a) = B (f a) newtype H f = H (f ()) app :: H (B t) app = h (H . I) (B ()) h :: _ --h :: Functor m => (a -> b) -> m a -> H m h f b = (H . fmap (const ())) (fmap f b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:08:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:08:06 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.64f92bc30b328f2c0052268e4ab7eb49@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: vlad.z.4096@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:08:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:08:28 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.43200f134df07554fc4fa58f581c6d37@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D876 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"f16ddcee0c64a92ab911a7841a8cf64e3ac671fd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f16ddcee0c64a92ab911a7841a8cf64e3ac671fd" Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. There are some minor BC changes to template-haskell to make it boot on GHC 7.8. Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:10:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:10:33 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.b95151af4497b2d3e12bc8c4283bdcfb@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can you give the output of `-dshow-passes` before and after reverting the patch? That should show if there is a big change in code size. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:12:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:12:57 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT Message-ID: <051.7ba9349b8474f729185a50676c86da71@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86 | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I have an expression {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} data Exp a where Fun :: (a -> b) - (Exp a -> Exp b) }}} and I want to create a pattern synonym for Int-expressions: {{{#!hs -- This works: -- pattern :: (a -> b) -> (Exp a -> Exp b) -- pattern IntFun f x = Fun f x pattern :: (Int -> Int) -> (Exp Int -> Exp Int) pattern IntFun f x = Fun f x }}} which results in {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:8:28: Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a pattern with constructor Fun :: forall b a. (a -> b) -> Exp a -> Exp b, in a pattern synonym declaration at Panic.hs:8:22 Expected type: Int -> Int Actual type: a -> Int Relevant bindings include b :: Exp a (bound at Panic.hs:8:28) a :: a -> Int (bound at Panic.hs:8:26) Failed, modules loaded: none. }}} So I try to be sneaky: {{{#!hs pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- % ghci -ignore-dot-ghci Panic.hs -- ? -- Couldn't match type ?a? with ?Int? -- ?a? is a rigid type variable bound by -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:22 }}} and if I constrain both type variables it panics {{{#!hs pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- Couldn't match type ?b? with ?Int? -- ?b? is untouchable -- inside the constraints () -- bound by the type signature for -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) -- (GHC version 7.10.0.20150316 for i386-unknown-linux): -- No skolem info: b_alF[sk] -- -- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The final version should look like: {{{#!hs type Name = String data Exp a where Fun :: Name -> (a -> b) -> (Exp a -> Exp b) ... pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun _ _ n where Suc n = Fun "suc" (+ 1) n }}} Shouldn't this work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:14:02 -0000 Subject: [GHC] #10384: "Can't splice the polymorphic local variable" check looks dead In-Reply-To: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> References: <045.accdef5b47d52ee6279151342275d1ae@haskell.org> Message-ID: <060.489032083c2b658b91ae1001a975df4a@haskell.org> #10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Re-committed as: {{{ commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd Author: Edward Z. Yang Date: Mon May 4 16:10:05 2015 -0700 Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. There are some minor BC changes to template-haskell to make it boot on GHC 7.8. Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382 }}} which merged all the patches together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:15:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:15:01 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.fa7564a2be823d060dfbbbb8c461fe83@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I have an expression > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a where > Fun :: (a -> b) - (Exp a -> Exp b) > }}} > > and I want to create a pattern synonym for Int-expressions: > > {{{#!hs > -- This works: > -- pattern :: (a -> b) -> (Exp a -> Exp b) > -- pattern IntFun f x = Fun f x > > pattern :: (Int -> Int) -> (Exp Int -> Exp Int) > pattern IntFun f x = Fun f x > }}} > > which results in > > {{{#!hs > % ghci -ignore-dot-ghci Panic.hs > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( Panic.hs, interpreted ) > > Panic.hs:8:28: > Couldn't match type ?a? with ?Int? > ?a? is a rigid type variable bound by > a pattern with constructor > Fun :: forall b a. (a -> b) -> Exp a -> Exp b, > in a pattern synonym declaration > at Panic.hs:8:22 > Expected type: Int -> Int > Actual type: a -> Int > Relevant bindings include > b :: Exp a (bound at Panic.hs:8:28) > a :: a -> Int (bound at Panic.hs:8:26) > Failed, modules loaded: none. > }}} > > So I try to be sneaky: > > {{{#!hs > pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- % ghci -ignore-dot-ghci Panic.hs > -- ? > -- Couldn't match type ?a? with ?Int? > -- ?a? is a rigid type variable bound by > -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp > b > -- at Panic.hs:8:22 > }}} > > and if I constrain both type variables it panics > > {{{#!hs > pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- Couldn't match type ?b? with ?Int? > -- ?b? is untouchable > -- inside the constraints () > -- bound by the type signature for > -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b > -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) > -- (GHC version 7.10.0.20150316 for i386-unknown-linux): > -- No skolem info: b_alF[sk] > -- > -- Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > The final version should look like: > > {{{#!hs > type Name = String > data Exp a where > Fun :: Name -> (a -> b) -> (Exp a -> Exp b) > ... > > pattern Suc :: Exp Int -> Exp Int > pattern Suc n <- Fun _ _ n where > Suc n = Fun "suc" (+ 1) n > }}} > > Shouldn't this work? New description: I have an expression {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} data Exp a where Fun :: (a -> b) -> (Exp a -> Exp b) }}} and I want to create a pattern synonym for Int-expressions: {{{#!hs -- This works: -- pattern :: (a -> b) -> (Exp a -> Exp b) -- pattern IntFun f x = Fun f x pattern :: (Int -> Int) -> (Exp Int -> Exp Int) pattern IntFun f x = Fun f x }}} which results in {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:8:28: Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a pattern with constructor Fun :: forall b a. (a -> b) -> Exp a -> Exp b, in a pattern synonym declaration at Panic.hs:8:22 Expected type: Int -> Int Actual type: a -> Int Relevant bindings include b :: Exp a (bound at Panic.hs:8:28) a :: a -> Int (bound at Panic.hs:8:26) Failed, modules loaded: none. }}} So I try to be sneaky: {{{#!hs pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- % ghci -ignore-dot-ghci Panic.hs -- ? -- Couldn't match type ?a? with ?Int? -- ?a? is a rigid type variable bound by -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:22 }}} and if I constrain both type variables it panics {{{#!hs pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- Couldn't match type ?b? with ?Int? -- ?b? is untouchable -- inside the constraints () -- bound by the type signature for -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) -- (GHC version 7.10.0.20150316 for i386-unknown-linux): -- No skolem info: b_alF[sk] -- -- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The final version should look like: {{{#!hs type Name = String data Exp a where Fun :: Name -> (a -> b) -> (Exp a -> Exp b) ... pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun _ _ n where Suc n = Fun "suc" (+ 1) n }}} Shouldn't this work? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:18:39 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.4a88e787fe8722a7027a66877055fffa@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by Artyom.Kazak: Old description: > The following code crashes GHC 7.10.1 as is, but doesn't result in a > crash if the signature is specified completely or isn't specified at all > (inferred): > > {{{#!hs > {-# LANGUAGE PartialTypeSignatures #-} > module Main where > > data I a = I a > instance Functor I where > fmap f (I a) = I (f a) > > newtype B t a = B a > instance Functor (B t) where > fmap f (B a) = B (f a) > > newtype H f = H (f ()) > > app :: H (B t) > app = h (H . I) (B ()) > > h :: _ > --h :: Functor m => (a -> b) -> m a -> H m > h f b = (H . fmap (const ())) (fmap f b) > }}} New description: The following code crashes GHC 7.10.1 as is, but doesn't result in a crash if the signature is specified completely or isn't specified at all (inferred): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} module Main where main :: IO () main = return () data I a = I a instance Functor I where fmap f (I a) = I (f a) newtype B t a = B a instance Functor (B t) where fmap f (B a) = B (f a) newtype H f = H (f ()) app :: H (B t) app = h (H . I) (B ()) h :: _ --h :: Functor m => (a -> b) -> m a -> H m h f b = (H . fmap (const ())) (fmap f b) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:33:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:33:17 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.f0573f0737e48ed531766874017d633b@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I fear the existential makes my `Suc` example trickier than I thought, even though it's orthogonal to my question I welcome suggestions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:33:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:33:17 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.e3fbe2f1087d302e16ebcfaba22008f3@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lelf): Seems to work correctly for HEAD-20150403 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:38:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:38:02 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.5803ecebfbe3c080f65867129ed78fe8@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Artyom.Kazak): Error message (in GHCi 7.10.1): {{{#!hs $ ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude Control.Applicative Control.Monad Data.Ratio> :l Bug.hs [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:18:10: Couldn't match type `b' with `H I' `b' is untouchable inside the constraints () bound by the type signature for app :: H (B t) at Bug.hs:17:8-14ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: b_aFd[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:47:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:47:45 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.237b5a53031070c1affbd854aba24313@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Artyom.Kazak): Possibly (most likely?) a duplicate of #10045. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 16:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 16:50:15 -0000 Subject: [GHC] #10402: powerpc: unhandled ELF relocation(RelA) type 252 In-Reply-To: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> References: <047.64cabbbba17f1f097b7e64d90dcccda9@haskell.org> Message-ID: <062.0bc18504a18712f159f0bd6b93de11d8@haskell.org> #10402: powerpc: unhandled ELF relocation(RelA) type 252 -----------------------------------+----------------------------------- Reporter: cjwatson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+----------------------------------- Comment (by rwbarton): No need to dig, just wanted to make sure you didn't know something to the contrary. And yes, we tend to just implement linker features as needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 17:24:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 17:24:22 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.fd77cf6c050a4e2352a4e82f2e0b2608@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I have an expression > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a where > Fun :: (a -> b) -> (Exp a -> Exp b) > }}} > > and I want to create a pattern synonym for Int-expressions: > > {{{#!hs > -- This works: > -- pattern :: (a -> b) -> (Exp a -> Exp b) > -- pattern IntFun f x = Fun f x > > pattern :: (Int -> Int) -> (Exp Int -> Exp Int) > pattern IntFun f x = Fun f x > }}} > > which results in > > {{{#!hs > % ghci -ignore-dot-ghci Panic.hs > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( Panic.hs, interpreted ) > > Panic.hs:8:28: > Couldn't match type ?a? with ?Int? > ?a? is a rigid type variable bound by > a pattern with constructor > Fun :: forall b a. (a -> b) -> Exp a -> Exp b, > in a pattern synonym declaration > at Panic.hs:8:22 > Expected type: Int -> Int > Actual type: a -> Int > Relevant bindings include > b :: Exp a (bound at Panic.hs:8:28) > a :: a -> Int (bound at Panic.hs:8:26) > Failed, modules loaded: none. > }}} > > So I try to be sneaky: > > {{{#!hs > pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- % ghci -ignore-dot-ghci Panic.hs > -- ? > -- Couldn't match type ?a? with ?Int? > -- ?a? is a rigid type variable bound by > -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp > b > -- at Panic.hs:8:22 > }}} > > and if I constrain both type variables it panics > > {{{#!hs > pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- Couldn't match type ?b? with ?Int? > -- ?b? is untouchable > -- inside the constraints () > -- bound by the type signature for > -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b > -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) > -- (GHC version 7.10.0.20150316 for i386-unknown-linux): > -- No skolem info: b_alF[sk] > -- > -- Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > The final version should look like: > > {{{#!hs > type Name = String > data Exp a where > Fun :: Name -> (a -> b) -> (Exp a -> Exp b) > ... > > pattern Suc :: Exp Int -> Exp Int > pattern Suc n <- Fun _ _ n where > Suc n = Fun "suc" (+ 1) n > }}} > > Shouldn't this work? New description: I have an expression {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} data Exp a where Fun :: (a -> b) -> (Exp a -> Exp b) }}} and I want to create a pattern synonym for Int-expressions: {{{#!hs -- This works: -- pattern IntFun :: (a -> b) -> (Exp a -> Exp b) -- pattern IntFun f x = Fun f x pattern IntFun :: (Int -> Int) -> (Exp Int -> Exp Int) pattern IntFun f x = Fun f x }}} which results in {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:8:28: Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a pattern with constructor Fun :: forall b a. (a -> b) -> Exp a -> Exp b, in a pattern synonym declaration at Panic.hs:8:22 Expected type: Int -> Int Actual type: a -> Int Relevant bindings include b :: Exp a (bound at Panic.hs:8:28) a :: a -> Int (bound at Panic.hs:8:26) Failed, modules loaded: none. }}} So I try to be sneaky: {{{#!hs pattern IntFun :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- % ghci -ignore-dot-ghci Panic.hs -- ? -- Couldn't match type ?a? with ?Int? -- ?a? is a rigid type variable bound by -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:22 }}} and if I constrain both type variables it panics {{{#!hs pattern IntFun :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- Couldn't match type ?b? with ?Int? -- ?b? is untouchable -- inside the constraints () -- bound by the type signature for -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) -- (GHC version 7.10.0.20150316 for i386-unknown-linux): -- No skolem info: b_alF[sk] -- -- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The final version should look like: {{{#!hs type Name = String data Exp a where Fun :: Name -> (a -> b) -> (Exp a -> Exp b) ... pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun _ _ n where Suc n = Fun "suc" (+ 1) n }}} Shouldn't this work? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 17:26:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 17:26:40 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.237f202a1ed6e1bce69ff142b0df159c@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Old description: > I have an expression > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a where > Fun :: (a -> b) -> (Exp a -> Exp b) > }}} > > and I want to create a pattern synonym for Int-expressions: > > {{{#!hs > -- This works: > -- pattern IntFun :: (a -> b) -> (Exp a -> Exp b) > -- pattern IntFun f x = Fun f x > > pattern IntFun :: (Int -> Int) -> (Exp Int -> Exp Int) > pattern IntFun f x = Fun f x > }}} > > which results in > > {{{#!hs > % ghci -ignore-dot-ghci Panic.hs > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( Panic.hs, interpreted ) > > Panic.hs:8:28: > Couldn't match type ?a? with ?Int? > ?a? is a rigid type variable bound by > a pattern with constructor > Fun :: forall b a. (a -> b) -> Exp a -> Exp b, > in a pattern synonym declaration > at Panic.hs:8:22 > Expected type: Int -> Int > Actual type: a -> Int > Relevant bindings include > b :: Exp a (bound at Panic.hs:8:28) > a :: a -> Int (bound at Panic.hs:8:26) > Failed, modules loaded: none. > }}} > > So I try to be sneaky: > > {{{#!hs > pattern IntFun :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- % ghci -ignore-dot-ghci Panic.hs > -- ? > -- Couldn't match type ?a? with ?Int? > -- ?a? is a rigid type variable bound by > -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp > b > -- at Panic.hs:8:22 > }}} > > and if I constrain both type variables it panics > > {{{#!hs > pattern IntFun :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- Couldn't match type ?b? with ?Int? > -- ?b? is untouchable > -- inside the constraints () > -- bound by the type signature for > -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b > -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) > -- (GHC version 7.10.0.20150316 for i386-unknown-linux): > -- No skolem info: b_alF[sk] > -- > -- Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > The final version should look like: > > {{{#!hs > type Name = String > data Exp a where > Fun :: Name -> (a -> b) -> (Exp a -> Exp b) > ... > > pattern Suc :: Exp Int -> Exp Int > pattern Suc n <- Fun _ _ n where > Suc n = Fun "suc" (+ 1) n > }}} > > Shouldn't this work? New description: I have an expression {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} data Exp a where Fun :: (a -> b) -> (Exp a -> Exp b) }}} and I want to create a pattern synonym for Int-expressions: {{{#!hs -- This works: -- pattern :: (a -> b) -> (Exp a -> Exp b) -- pattern IntFun f x = Fun f x pattern :: (Int -> Int) -> (Exp Int -> Exp Int) pattern IntFun f x = Fun f x }}} which results in {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:8:28: Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a pattern with constructor Fun :: forall b a. (a -> b) -> Exp a -> Exp b, in a pattern synonym declaration at Panic.hs:8:22 Expected type: Int -> Int Actual type: a -> Int Relevant bindings include b :: Exp a (bound at Panic.hs:8:28) a :: a -> Int (bound at Panic.hs:8:26) Failed, modules loaded: none. }}} So I try to be sneaky: {{{#!hs pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- % ghci -ignore-dot-ghci Panic.hs -- ? -- Couldn't match type ?a? with ?Int? -- ?a? is a rigid type variable bound by -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:22 }}} and if I constrain both type variables it panics {{{#!hs pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- Couldn't match type ?b? with ?Int? -- ?b? is untouchable -- inside the constraints () -- bound by the type signature for -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) -- (GHC version 7.10.0.20150316 for i386-unknown-linux): -- No skolem info: b_alF[sk] -- -- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The final version should look like: {{{#!hs type Name = String data Exp a where Fun :: Name -> (a -> b) -> (Exp a -> Exp b) ... pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun _ _ n where Suc n = Fun "suc" (+ 1) n }}} Shouldn't this work? -- Comment (by Iceland_jack): A quick but unsatisfying solution was adding a tag: {{{#!hs data Tag ty where ITag :: Tag Int ? data Exp a where Fun? :: Name -> Tag a -> (a -> b) -> (Exp a -> Exp b) Fun? :: Name -> Tag a -> Tag b -> (a -> b -> c) -> (Exp a -> Exp b -> Exp c) ? pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun? "suc" _succ n where Suc n = Fun? "suc" succ n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 17:30:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 17:30:22 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.102ded546c5610350a846d7aa2822ead@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by ekmett): One reason for not following semver exactly is that the PVP doesn't line up exactly with semver. Both of our first two digits are "major", and we allow as many subsequent digits as we want. We also don't have an observable prerelease tag for better or worse. As for version tags being ignored by the `Eq` instance. That would have been a viable alternative, but it would have meant that `Version` still didn't line up with what we use it for in ghc, cabal, and elsewhere. IIRC the main use of the tags currently is to talk about a version "*" in some internals in places. A "structural" `Eq` has the benefit that `x == y` implies `f x == f y`, and doesn't require the user to track the exception to the semantics they expect for equality, whereas under your suggestion we'd lose that. It'd just be 'some place to shove extra stuff' bolted onto a data type that could be fundamentally simpler. Then if users want to work with a tagged version they can build it by one of several means, for whatever notions of tags they want to allow, using the existing `Version` type as a primitive component in their own tagged version type with tags being relevant or not for equality as they choose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 18:29:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 18:29:18 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.265933ec6de481486228042b5c84cebe@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michalt): tl;dr: No difference If anyone wants to try to reproduce: checkout b0379819e46796047c1574a6abccf186afd27afa and then revert b8392ae76a6d39c57be94b5ba041c450ab479e2b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 19:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 19:21:44 -0000 Subject: [GHC] #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp Bool) Message-ID: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp Bool) -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Linux (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: x86 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following compiles just fine: {{{#!hs data Exp a where B :: Bool -> Exp Bool pattern Tru = B True pr :: Exp a -> String pr Tru = "true" }}} but add a signature to `Tru`? {{{#!hs pattern Tru :: Exp Bool pattern Tru = B True }}} ?and it fails to compile {{{#!hs % ghci -ignore-dot-ghci /tmp/Bug.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted ) /tmp/Bug.hs:11:4: Couldn't match type ?a? with ?Bool? ?a? is a rigid type variable bound by the type signature for pr :: Exp a -> String at /tmp/Bug.hs:10:7 Expected type: Exp a Actual type: Exp Bool Relevant bindings include pr :: Exp a -> String (bound at /tmp/Bug.hs:11:1) In the pattern: Tru In an equation for ?pr?: pr Tru = "true" Failed, modules loaded: none. }}} Checking the inferred type of `pattern Tru = B True` I get {{{#!hs ghci> :i Tru pattern Tru :: t ~ Bool => Exp t }}} which works as expected {{{#!hs pattern Tru :: t ~ Bool => Exp t pattern Tru = B True pr :: Exp a -> String pr Tru = "true" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 19:24:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 19:24:50 -0000 Subject: [GHC] #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) (was: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp Bool)) In-Reply-To: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> References: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> Message-ID: <066.ec9687fcebf33dda344391137dff07b7@haskell.org> #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 19:34:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 19:34:48 -0000 Subject: [GHC] #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) In-Reply-To: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> References: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> Message-ID: <066.b62dd191795368dc78bd884654190978@haskell.org> #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: invalid | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: I think this is all expected behavior, although the syntax is confusing. See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /syntax-extns.html#idp23521760 and especially the item "In the common case where CReq is empty, (), it can be omitted altogether." In fact, your example is very similar to the last item under 7.3.9.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 20:17:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 20:17:53 -0000 Subject: [GHC] #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) In-Reply-To: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> References: <051.8cceb369921c3f590e05addf78e6e132@haskell.org> Message-ID: <066.2de53d83f7db3f5c44903196eac3f1e0@haskell.org> #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp t) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: invalid | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Egg on my face, I should have realised that. Thanks for the response. For anyone in a similar situation and for future evaluation of #9953 I have the expression: {{{#!haskell data Tag a where TInt :: Tag Int TBool :: Tag Bool ? data Exp a where Fn? :: String -> Tag a -> (a -> b) -> (Exp a -> Exp b) Fn? :: String -> Tag a -> Tag b -> (a -> b -> c) -> (Exp a -> Exp b -> Exp c) ? }}} To be able to match against expressions of type `Exp a` I needed to add an additional tag for the return type: {{{#!haskell data Exp a where Fn? :: String -> Tag a -> Tag b -> (a -> b) -> (Exp a -> Exp b) Fn? :: String -> Tag a -> Tag b -> Tag c -> (a -> b -> c) -> (Exp a -> Exp b -> Exp c) ? }}} {{{#!haskell pattern Leq :: (a ~ Int, b ~ Int, c ~ Bool) => Exp a -> Exp b -> Exp c pattern Leq a b ? Fn? "leq" TInt TInt TBool _ a b where Leq a b = Fn? "leq" TInt TInt TBool (<=) a b }}} is the final version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 22:32:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 22:32:18 -0000 Subject: [GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. In-Reply-To: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> References: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> Message-ID: <059.88c8eac261bd2334713ee2a0f3f98b3d@haskell.org> #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D873 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 22:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 22:32:26 -0000 Subject: [GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place In-Reply-To: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> References: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> Message-ID: <059.abde5283da9104b8c8fe41ed58919e60@haskell.org> #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D869 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 22:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 22:32:29 -0000 Subject: [GHC] #10287: ApiAnnotations : BooleanFormula construction discards original In-Reply-To: <044.dc10540293e80736094df33a8e676e4d@haskell.org> References: <044.dc10540293e80736094df33a8e676e4d@haskell.org> Message-ID: <059.c1a0271d6aa5d37b5302a934ae6e56da@haskell.org> #10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D837 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 22:32:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 22:32:37 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy In-Reply-To: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> References: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> Message-ID: <059.94955e8c7a2355db06238a149960cd77@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D848 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 11 22:32:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 May 2015 22:32:44 -0000 Subject: [GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. In-Reply-To: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> References: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> Message-ID: <059.a6eab2d48a6f83322f68e0955843c7e6@haskell.org> #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D842 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 04:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 04:34:20 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.2abfb56ffaccbe01905996dcf42334ff@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by zilinc): At least from my own perspective, I think removing versionTags to retain some properties is rational (well to be honest in this particular case I don't even care). And, exactly as Edward said, I just need a replacement. So I simply did as little change as in https://github.com/haskell/cabal/pull/2584 to accomplish that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 04:49:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 04:49:11 -0000 Subject: [GHC] #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! Message-ID: <050.69a1127c662d09f1c26088e7d11c9d3b@haskell.org> #10406: ghc-7.10.1-testsuite.tar.xz [4.3MB] contains x86_64 ghc-config executable! -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: Build | Operating System: Unknown/Multiple System | Type of failure: Building GHC Keywords: | failed Architecture: x86 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I didn't check ghc-7.10.1-testsuite.tar.bz2 but at least ghc-7.10.1-testsuite.tar.xz contains testsuite/mk/ghc-config which is a 64bit Linux executable. This causes the testsuite to fail on non-x86_64 arches eg i686 Linux, etc since it can't be executed. A workaround is to rm testsuite/mk/ghc-config. It would be good to avoid this for 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 04:50:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 04:50:31 -0000 Subject: [GHC] #10407: git head no longer builds with ghc < 7.10 Message-ID: <044.8b677a8bd494e4a9fff99b4cb8a322a7@haskell.org> #10407: git head no longer builds with ghc < 7.10 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building git head after commit 4fffbc34c0 with ghc-7.8 or ghc-7.6 I get: {{{ compiler/typecheck/TcInteract.hs:2034:13: Not in scope: ?<$>? Perhaps you meant one of these: ?TcM.<$>? (imported from TcRnMonad), ?<+>? (imported from Outputable), ?TcM.<*>? (imported from TcRnMonad) compiler/typecheck/TcInteract.hs:2034:29: Not in scope: ?<$>? Perhaps you meant one of these: ?TcM.<$>? (imported from TcRnMonad), ?<+>? (imported from Outputable), ?TcM.<*>? (imported from TcRnMonad) }}} The `<$>` operator is only available by default in ghc 7.10 and later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 04:59:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 04:59:32 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird Message-ID: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- {{{ $ for i in `seq 10`; do echo "print $i" > /tmp/$i.ghci; done $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci 2 1 0 $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot- ghci 0 }}} `-ghci-script` are executed in reverse order and are ignored when `-ignore-dot-ghci` is specified, while I expected that: * `-ghci-script` are executed in the order they are specified; * `-ignore-dot-ghci` only ignores the default .ghci files but still executes the scripts passed by `-ghci-script`. I would like to change the behavior to the expected ones. But in case there are users relying on the old behavior, then it might be necessary to introduce different flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 05:23:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 05:23:59 -0000 Subject: [GHC] #10407: git head no longer builds with ghc < 7.10 In-Reply-To: <044.8b677a8bd494e4a9fff99b4cb8a322a7@haskell.org> References: <044.8b677a8bd494e4a9fff99b4cb8a322a7@haskell.org> Message-ID: <059.339cd5a07d02586630ad30b1f0a3ba89@haskell.org> #10407: git head no longer builds with ghc < 7.10 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"c119a8020f4e3073460e2c350507d5cf65771cea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c119a8020f4e3073460e2c350507d5cf65771cea" Use fmap instead of <$> (Fixes #10407) The <$> operator is only available in the standard Prelude in ghc 7.10 and later. Signed-off-by: Erik de Castro Lopo Test Plan: build with ghc-7.6 Reviewers: dterei, ezyang, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D886 GHC Trac Issues: #10407 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 05:25:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 05:25:19 -0000 Subject: [GHC] #10407: git head no longer builds with ghc < 7.10 In-Reply-To: <044.8b677a8bd494e4a9fff99b4cb8a322a7@haskell.org> References: <044.8b677a8bd494e4a9fff99b4cb8a322a7@haskell.org> Message-ID: <059.7dab176bb7263758cd8f932b14e81ad4@haskell.org> #10407: git head no longer builds with ghc < 7.10 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 06:05:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 06:05:32 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird In-Reply-To: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> References: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> Message-ID: <061.99c8f10d21acb769cee6d63e63fba7ab@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D887 Related Tickets: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D887 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 06:35:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 06:35:30 -0000 Subject: [GHC] #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. Message-ID: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: cross- | Operating System: Linux compiling | Type of failure: Runtime crash Architecture: aarch64 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling a simple "hello-world" program with an amd64/linux to aarch64/linux cross compiler built from the current `ghc-7.10` branch results in a binary that segfaults as soon as it is run. A cross compiler build from the master branch works and I thought it also worked for `ghc-7.10`. A native aarch64/linux compiler built from the `ghc-7.10` branch works correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 07:49:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 07:49:10 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.7d20b00cbd56ccbbd05913e11aa7f8eb@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by literon): Just +1-ing to express my support for full binary determinism. Reproducible builds are important for efficiency and verification purposes in the distributed and containerized world. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 10:52:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 10:52:45 -0000 Subject: [GHC] #10410: make install installs haddck.t files Message-ID: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> #10410: make install installs haddck.t files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since changeset:55cdcc96/ghc, building GHC creates `.haddock.t` files with statistics. I?m not sure how useful they are in general, but they are definitely not useful in release tarballs. Currently, `make install` copies them. This affects both the binary release on the ghc page as well as distribution packages (checked Debian and Fedora). It seems these files are used by the test suite (`testsuite/tests/perf/haddock/all.T`), so probably `make install` should be taught to ignore them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 12:36:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 12:36:21 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant Message-ID: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ > :set -fno-max-relevant-binds > let a = True; b = _ in undefined :3:19: Found hole ?_? with type: t1 Where: ?t1? is a rigid type variable bound by the inferred type of b :: t1 at :3:15 Relevant bindings include b :: t1 (bound at :3:15) it :: t (bound at :3:1) In the expression: _ In an equation for ?b?: b = _ In the expression: let a = True b = _ in undefined }}} Somehow a is not there, even though b itself is. Tested with 7.8.3 and 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 13:56:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 13:56:14 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird In-Reply-To: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> References: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> Message-ID: <061.3ab855a851cba7d3d76af2ee1b39c34e@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D887 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f5188f3acd73a07b648924a58b9882c2d0a3dbcb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f5188f3acd73a07b648924a58b9882c2d0a3dbcb" Fix weird behavior of -ignore-dot-ghci and -ghci-scipt * Make `-ghci-script` be executed in the order they are specified; * Make `-ignore-dot-ghci` only ignores the default .ghci files but still execute the scripts passed by `-ghci-script`. Reviewed By: simonmar, austin Differential Revision: https://phabricator.haskell.org/D887 GHC Trac Issues: #10408 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 14:27:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 14:27:05 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.e631af2e2e0f11bc468d6229cc1cff3f@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by AlexET): * owner: => AlexET -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 15:03:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 15:03:30 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.0d077e44277d9f492b8513ada9a20c9f@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 -------------------------------------+------------------------------------- Comment (by beroal): What about people who use tab characters for indentation regularly? My code looks correct for any tab character width chosen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 19:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 19:45:14 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.b3fd142584f476ea2a93ae830a646f61@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mjmrotek): I'm getting a similar panic on Windows 8 x86_64 (latest MinGHC) from GHC 7.10.1 when compiling the UoM Plugin (https://github.com/adamgundry/uom- plugin): [11 of 13] Compiling Data.UnitsOfMeasure.Convert ( src\Data\UnitsOfMeasure\Convert.hs dist\build\Data\UnitsOfMeasure\Convert.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-mingw32): Static flags have not been initiailised! Please call GHC.parseStaticFlags early enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 20:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 20:12:48 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant In-Reply-To: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> References: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> Message-ID: <063.171674dedbbcc45dd4b4685261f5017a@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): GHC reports an enclosing binding as "relevant" if its type mentions a type variable used in the type of the hole. Here we have `b :: forall t1.t1`, whereas `a::Bool`. So `a` is not mentioned as relevant. You obviously wish that it was. How could we define "relevant" better? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 12 22:44:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 May 2015 22:44:27 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.1034addabe1f75834aa2f79296f19b91@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"4b8b4ce12a1b5f682071a27bc313649fa50e0e91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b8b4ce12a1b5f682071a27bc313649fa50e0e91" Fix fragile T9579 tests Fix fragile tests according to comment 13 of #9579 (by @bherzog) Done by capturing stderr and replace `xx bytes` with `NUM bytes` (literal). Some numbers like `(1 MB)` would still remain, but I think it's safe to assume the actual difference in bytes (on different architectures) is too small to have an effect on the rounded megabyte value. Test Plan: validate Reviewers: erikd, austin Reviewed By: erikd, austin Subscribers: erikd, bgamari, thomie, bherzog Differential Revision: https://phabricator.haskell.org/D882 GHC Trac Issues: #9579 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 01:24:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 01:24:04 -0000 Subject: [GHC] #10368: STM test failing on Armhf/Linux In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.5e0ed5a28b8be5f174a770368433f2cd@haskell.org> #10368: STM test failing on Armhf/Linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #7815 | -------------------------------------+------------------------------------- Comment (by erikd): From @fryguybob on IRC : The right thing to do would probably be to see what it would take to build that part of the RTS with C11 atomics. There might be some relivant cmm code, but I think all of the locking is conveniently located in C land. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 03:07:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 03:07:16 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.b13249371307b6596d29f5704a8df058@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 03:10:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 03:10:03 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird In-Reply-To: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> References: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> Message-ID: <061.f8bb63943bae912379a57c7f4dc25ccf@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D887 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * milestone: => 7.12.1 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 06:31:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 06:31:16 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.188e82e0c4cca2397594bd455d56a3a0@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I was chatting with one of my colleagues about this problem recently, and they said something very provocative: if GHC is not scaling because there is some global mutable state (e.g. the NameCache) which all the threads are hitting, it doesn't make sense to try to fix the compiler to scale; you should just run multiple processes of the compiler in parallel (like GHC's build does). Guaranteed scaling! Do people agree with this viewpoint? Disagree? If we take this viewpoint seriously, we should spend more time improving GHC's ability to output the dependency analysis for other tools to then build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 08:01:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 08:01:38 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.59a3f68accbe124791847d483e2a6156@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="130e93aab220bdf14d08028771f83df210da340b" Refactor tuple constraints Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 08:01:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 08:01:38 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.4f7d58ff84a00e6ed7da5fa259bbfebc@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="130e93aab220bdf14d08028771f83df210da340b" Refactor tuple constraints Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 08:10:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 08:10:16 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.4f4bb49838bc1b1cc447fbbfb6be9954@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: eridk, cjwatson (added) * milestone: => 7.10.2 Comment: This obviously affects distributions. If someone finds a fix, can we backport this to 7.10? (Setting milestone to 7.10.2, but 7.10.3 would be fine with me as well.) Adding Erik and Colin to the CC list, they might know more about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 08:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 08:11:15 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' In-Reply-To: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> References: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> Message-ID: <060.f5517d6513ad487c1a93df3cac6004a4@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Compiler | Milestone: 7.10.1 Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Might this be related to #10244? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 09:23:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 09:23:32 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.2199538e5fbcbec6c40def3fb67645ce@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Actually it's fine in HEAD and should stay that way, i.e. NOT as I said in comment:5. See `Note [Instance and Given overlap]` in `TcInteract`. I'll close as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 09:28:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 09:28:51 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.e8bdfc3e67ca8e523c1e8a7b24f9461f@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Alternatively, give each thread its own `NameCache`. To do that, if one thread consumes a `ModIface` produced by another, it'd need to run over it, looking up all the `Names` to give them the `Unique` local to that thread. Not so very different to having entirely separate processes communicating through files; and the latter is perhaps easier to think about. So, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 12:44:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 12:44:57 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.975fb9d9b555c028a064ea81d1a5debd@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D889 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D889 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 13:55:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 13:55:08 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' In-Reply-To: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> References: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> Message-ID: <060.6a22e9c25fc2f53f9ba3070e85efabea@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Compiler | Milestone: 7.10.1 Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, it's definitely the cause. Effectively this change turned the behavior for architectures that don't have a specific memory barrier implementation from "do nothing and hope for the best" to "raise a compile-time error". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 13:58:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 13:58:32 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do Message-ID: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: unicode | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs > isMark '\768' True > isAlphaNum '\768' True > (isAlpha '\768', isNumber '\768') (False,False) }}} This behavior comes from this piece in WCsubst.c: {{{ unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO| GENCAT_MC|GENCAT_ME|GENCAT_MN| GENCAT_NO|GENCAT_ND|GENCAT_NL)) }}} I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++? (And if it's a feature and not a bug, then it should definitely be documented.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 14:06:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 14:06:24 -0000 Subject: [GHC] #10413: Incorrect offsets for array size indexing Message-ID: <048.fb282c815f959019fb8541a09f28e9ea@haskell.org> #10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There are several cases in the array code generation where a byte offset is used when a word offset is needed. For example ([https://git.haskell.org/ghc.git/blob/eb6ca851f553262efe0824b8dcbe64952de4963d:/compiler/codeGen/StgCmmPrim.hs#l426 context]): {{{#!hs emitPrimOp dflags [res] SizeofSmallArrayOp [arg] = emit $ mkAssign (CmmLocal res) (cmmLoadIndexW dflags arg (fixedHdrSizeW dflags + oFFSET_StgSmallMutArrPtrs_ptrs dflags) (bWord dflags)) }}} This only works because `oFFSET_StgSmallMutArrPtrs_ptrs dflags` is zero. I don't have time to fix this now, but I'm reporting it so it isn't forgotten. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:22:21 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.6e129164d0df29608f542ef59eb4cc51@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c0aae6f699cbd222d826d0b8d78d6cb3f682079e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0aae6f699cbd222d826d0b8d78d6cb3f682079e" Test Trac #10248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:22:21 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.f17a14a9b76541ac678867f0fa9b2866@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a9ccd37add8315e061c02e5bf26c08f05fad9ac9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a9ccd37add8315e061c02e5bf26c08f05fad9ac9" Test Trac #10403 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:22:21 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.e2320823e2afb9f85be6742e5f8c74cd@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf" Test Trac #10359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:22:50 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.1e5710d7e174664a24ea73aeefdb18c3@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | perf/should_run/T10359 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => perf/should_run/T10359 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:32:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:32:30 -0000 Subject: [GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird In-Reply-To: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> References: <046.9a385a1c8826dd0a905fd10c48159e27@haskell.org> Message-ID: <061.06694b31701faa3d08ac79eba5d338a6@haskell.org> #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D887 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: watashi => * status: closed => new * resolution: fixed => Comment: SPJ [https://mail.haskell.org/pipermail/ghc-devs/2015-May/009005.html reports]: {{{ Strange testsuite failure Is this expected? Just started happening for me =====> T8333(normal) 140 of 185 [0, 0, 0] cd . && $MAKE -s --no-print-directory T8333 T8333.run.stdout 2> T8333.run.stderr Actual stdout output differs from expected: --- ./T8333.stdout 2015-01-27 13:00:30.000000000 +0000 +++ ./T8333.run.stdout 2015-05-13 11:54:03.199711197 +0100 @@ -0,0 +1,4 @@ +*** WARNING: . is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 .' +*** WARNING: /home/simonpj is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 /home/simonpj' *** unexpected failure for T8333(normal) }}} I think this is related to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:45:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:45:11 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.5be2f3fdf5a577cc36cce6f3df41907e@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Seems ok in 7.10 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 16:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 16:45:19 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.b214405970e73c7e227ce382871ea5d7@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Seems ok in 7.10 too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 18:48:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 18:48:53 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) Message-ID: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling the test case with: ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs Now, trying with some inputs and -N2 $ ./ghc-bug 7 +RTS -N2 => ghc-bug: <> $ ./ghc-bug 6 +RTS -N2 => ghc-bug: <> $ ./ghc-bug 5 +RTS -N2 => 3125 $ ./ghc-bug 5 +RTS -N2 ghc-bug: <> Reducing the number of capabilities to 1, it works for those inputs $ ./ghc-bug 7 +RTS -N1 As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [http://lpaste.net/132564/ original testcase] felt a bit more deterministic, but I think the testcase in the ticket is good enough) I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian Similar bug: [10218] (-fno-cse and -flate-dmd-anal didn't help with this) {{{#!hs import Control.Applicative import Control.Monad import Control.Parallel.Strategies import System.Environment newtype ParList a = ParList { unParList :: [a] } nil :: ParList a nil = ParList [] cons :: a -> ParList a -> ParList a cons x (ParList xs) = ParList (x:xs) instance Functor ParList where fmap = liftM instance Applicative ParList where pure = return (<*>) = ap instance Monad ParList where return = ParList . return {- v code that doesn't work -} (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs >>= unParList . f)) --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs)) {- ^ code that works -} type Pair = (Int, [Int]) loop' :: Pair -> ParList Pair loop' (size,qns) = go 1 where go n | n > size = nil | otherwise = cons (size, n:qns) (go (n+1)) worker :: Int -> Pair -> [Pair] worker n = unParList . go n where go 1 = loop' go n = loop' >=> go (n-1) main :: IO () main = do [n] <- (read <$>) <$> getArgs print $ length (worker n (n,[])) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 18:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 18:52:10 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.813a9570d021c992f9da3c5c53a79a16@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by rwbarton: Old description: > Compiling the test case with: > > ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs > > Now, trying with some inputs and -N2 > $ ./ghc-bug 7 +RTS -N2 > => ghc-bug: <> > $ ./ghc-bug 6 +RTS -N2 > => ghc-bug: <> > $ ./ghc-bug 5 +RTS -N2 > => 3125 > $ ./ghc-bug 5 +RTS -N2 > ghc-bug: <> > > Reducing the number of capabilities to 1, it works for those inputs > $ ./ghc-bug 7 +RTS -N1 > > As a side-note, the problem only happens randomly with small inputs (on > my hardware), and it seems to go away with bigger inputs (the > [http://lpaste.net/132564/ original testcase] felt a bit more > deterministic, but I think the testcase in the ticket is good enough) > > I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported > the same behavior with GHC 7.10.1 on OS X and Debian > > Similar bug: [10218] (-fno-cse and -flate-dmd-anal didn't help with this) > > {{{#!hs > import Control.Applicative > import Control.Monad > > import Control.Parallel.Strategies > > import System.Environment > > newtype ParList a = ParList { unParList :: [a] } > > nil :: ParList a > nil = ParList [] > cons :: a -> ParList a -> ParList a > cons x (ParList xs) = ParList (x:xs) > > instance Functor ParList where > fmap = liftM > > instance Applicative ParList where > pure = return > (<*>) = ap > > instance Monad ParList where > return = ParList . return > {- v code that doesn't work -} > (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs > >>= unParList . f)) > --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) > xs)) > {- ^ code that works -} > > type Pair = (Int, [Int]) > > loop' :: Pair -> ParList Pair > loop' (size,qns) = go 1 > where go n | n > size = nil > | otherwise = cons (size, n:qns) (go (n+1)) > > worker :: Int -> Pair -> [Pair] > worker n = unParList . go n > where go 1 = loop' > go n = loop' >=> go (n-1) > > main :: IO () > main = do > [n] <- (read <$>) <$> getArgs > print $ length (worker n (n,[])) > > }}} New description: Compiling the test case with: ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs Now, trying with some inputs and -N2 $ ./ghc-bug 7 +RTS -N2 => ghc-bug: <> $ ./ghc-bug 6 +RTS -N2 => ghc-bug: <> $ ./ghc-bug 5 +RTS -N2 => 3125 $ ./ghc-bug 5 +RTS -N2 ghc-bug: <> Reducing the number of capabilities to 1, it works for those inputs $ ./ghc-bug 7 +RTS -N1 As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [http://lpaste.net/132564/ original testcase] felt a bit more deterministic, but I think the testcase in the ticket is good enough) I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian Similar bug: #10218 (-fno-cse and -flate-dmd-anal didn't help with this) {{{#!hs import Control.Applicative import Control.Monad import Control.Parallel.Strategies import System.Environment newtype ParList a = ParList { unParList :: [a] } nil :: ParList a nil = ParList [] cons :: a -> ParList a -> ParList a cons x (ParList xs) = ParList (x:xs) instance Functor ParList where fmap = liftM instance Applicative ParList where pure = return (<*>) = ap instance Monad ParList where return = ParList . return {- v code that doesn't work -} (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs >>= unParList . f)) --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs)) {- ^ code that works -} type Pair = (Int, [Int]) loop' :: Pair -> ParList Pair loop' (size,qns) = go 1 where go n | n > size = nil | otherwise = cons (size, n:qns) (go (n+1)) worker :: Int -> Pair -> [Pair] worker n = unParList . go n where go 1 = loop' go n = loop' >=> go (n-1) main :: IO () main = do [n] <- (read <$>) <$> getArgs print $ length (worker n (n,[])) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 19:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 19:30:10 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.901e9df835da65386ded04a2babeb07b@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I get the same behavior with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 19:54:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 19:54:24 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.ef5653354a8f11e1d3da5c559e9c5f75@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Changes (by javran): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 19:55:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 19:55:58 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.f355ad7c32b06f4c85c95747354716f1@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by javran): Things mentioned here are all done so I mark this ticket as closed. :) Feel free to open if there are still questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 20:42:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 20:42:53 -0000 Subject: [GHC] #10415: ForeignPtr touched in FFI wrapper is never discarded Message-ID: <047.76bac1b4c37897ce4c2d32d79bc5296f@haskell.org> #10415: ForeignPtr touched in FFI wrapper is never discarded -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If a `ForeignPtr` is touched in an FFI wrapper (`foreign import ccall "wrapper"`), it appears to never be discarded. For example, the program below demonstrates a space leak due to multiple `mallocForeignPtrBytes` results hanging around forever. {{{#!hs import Control.Concurrent (threadDelay) import Foreign.ForeignPtr import Foreign.Marshal.Utils (fillBytes) import Foreign.Ptr (FunPtr) foreign import ccall "wrapper" wrap :: IO () -> IO (FunPtr (IO ())) main :: IO () main = flip mapM_ [0..50] $ \_ -> do let len = 30 * 2^20 fp <- mallocForeignPtrBytes len withForeignPtr fp $ \p -> fillBytes p 0 len _ <- wrap $ touchForeignPtr fp threadDelay 100000 }}} Each of the 50 iterations allocates 30 megabytes of memory via `mallocForeignPtrBytes`. None of those allocations is ever freed, resulting in around 1.5 gigabytes of memory use by the time the program terminates. (Neither `fillBytes` nor `threadDelay` are required to reproduce the issue: they are there to respectively touch the memory so that it's fully allocated by the OS and to slow the program down so that one can view the memory usage gradually increasing e.g. with `top`.) Example run, with almost 1.6 gigabytes of memory usage reported by GNU time (the "maxresident" bit): {{{ $ ghc --make asdf.hs [1 of 1] Compiling Main ( asdf.hs, asdf.o ) Linking asdf ... $ /usr/bin/time ./asdf 0.12user 0.54system 0:05.77elapsed 11%CPU (0avgtext+0avgdata 1587300maxresident)k 0inputs+0outputs (0major+138078minor)pagefaults 0swaps }}} People bitten by this can probably work around it without too much trouble by either: 1. Simply avoiding the trigger, i.e. `touchForeignPtr` in a wrapper. In my case, that amounts to changing some functions to take `Ptr a` instead of `ForeignPtr a` and moving some `withForeignPtr` calls around, possibly adding manual `touchForeignPtr` calls somewhere. 2. Switching to manual memory management with functions like `mallocBytes` and `free`. But the issue seems rather nasty regardless. (At least it took me a while to pin down.) Hopefully it can be fixed without too much trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:13:07 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.5010cbac61866885162c5fda3a3f700e@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: Do you have a particular build error? I wonder what else is visible there. From what I see in the '''includes/stg/SMP.h''' it's just omission in implementation. There is properly-looking '''write_barrier''' {{{ EXTERN_INLINE void write_barrier(void) { ... #elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7) __asm__ __volatile__ ("" : : : "memory"); #elif (arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7)) || aarch64_HOST_ARCH __asm__ __volatile__ ("dmb st" : : : "memory"); ... }}} but not load_load: {{{ EXTERN_INLINE void load_load_barrier(void) { ... #elif arm_HOST_ARCH && !defined(arm_HOST_ARCH_PRE_ARMv7) __asm__ __volatile__ ("dmb" : : : "memory"); ... }}} I think stubbing out with {{{ __asm__ __volatile__ ("" : : : "memory"); }}} is best we can do there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:20:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:20:22 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.52790f6a9426b0d8c0940a4c4a52d74b@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by slyfox): Can you try this patch on a real host to see if it's the only omission? If it's fine I'll make a proper Phab DR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:21:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:21:50 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.1f9474c8dffb28383a081c8921eccd48@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by cjwatson): You can do a little better for ARMv6 with mcr p15: the [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/include/asm/barrier.h Linux kernel] has some examples. I don't know if this is worth bothering with in practice though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:22:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:22:06 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.66c0e006a03ba390de5ff75c70f700de@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): Compiling with `-debug` I sometimes get {{{ BrokenCode: internal error: ASSERTION FAILED: file rts/Schedule.c, line 570 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:30:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:30:01 -0000 Subject: [GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do In-Reply-To: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> References: <051.04054b116946e9bf810283d6d73d9ff5@haskell.org> Message-ID: <066.cf799041a1dd99c78528c356cc56d37f@haskell.org> #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): For the record, this was already an issue on GHC 7.8.4 (through GHC 7.0.4): {{{ GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help ?> import Data.Char ?> length $ filter isMark $ filter (\c -> isAlphaNum c /= (isAlpha c && isNumber c)) ['\0'..] 1281 }}} {{{ GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help ?> import Data.Char ?> length $ filter isMark $ filter (\c -> isAlphaNum c /= (isAlpha c && isNumber c)) ['\0'..] 1498 }}} {{{ GHCi, version 7.10.1.20150511: http://www.haskell.org/ghc/ :? for help ?> import Data.Char ?> length $ filter isMark $ filter (\c -> isAlphaNum c /= (isAlpha c && isNumber c)) ['\0'..] 1830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:37:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:37:20 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.bc25a88fd25d622ad591d5f929f0c9d4@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): I simplified the problem a little. The first command line argument is for the chunk size given to `parListChunk`: {{{#!hs import Control.Parallel.Strategies import System.Environment type Pair = (Int, [Int]) loop' :: Pair -> [Pair] loop' (size,qns) = go 1 where go n | n > size = [] | otherwise = (size, n:qns) : (go (n+1)) worker :: Int -> Int -> Pair -> [Pair] worker chunksize = go where go 1 = loop' go n = withStrategy (parListChunk chunksize rseq) . concatMap (go (n-1)) . loop' main :: IO () main = do chunksize:n:_ <- fmap (map read) getArgs print $ length (worker chunksize n (n,[])) }}} With this i get, e.g.: {{{ $ ghc -O2 -threaded -rtsopts -fforce-recomp threads.hs $ time ./threads 8 7 +RTS -N1 823543 real 0m2.133s user 0m2.025s sys 0m0.097s $ time ./threads 8 7 +RTS -N2 threads: <> real 0m0.368s user 0m0.074s sys 0m0.016s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 13 22:49:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 May 2015 22:49:50 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.6b346f358166627436b157b4a99c0d99@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:33 beroal]: > What about people who use tab characters for indentation regularly? My code looks correct for any tab character width chosen. People who are sure they know what they're doing can use the `-fno-warn- tabs` flag. The reason for making this the default is that tabs trip up a ''lot'' of people who are new to Haskell. It also makes their pleas for help ''extremely'' confusing and time-wasting on a site like Stack Overflow, which autoconverts tabs to spaces - with a ''different'' width rule than Haskell uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 03:45:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 03:45:21 -0000 Subject: [GHC] #10415: ForeignPtr touched in FFI wrapper is never discarded In-Reply-To: <047.76bac1b4c37897ce4c2d32d79bc5296f@haskell.org> References: <047.76bac1b4c37897ce4c2d32d79bc5296f@haskell.org> Message-ID: <062.e5ba772abd61a25df9521cc02fcd6049@haskell.org> #10415: ForeignPtr touched in FFI wrapper is never discarded -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: The `FunPtr`s produced by a wrapper are like `Ptr`s, not `ForeignPtr`s. The functions they point to aren't and can't be managed by GC, because you can pass one directly to a C function and it can squirrel the pointer away in a C data structure somewhere. So the wrapped functions in this program live forever, and since they refer to the `ForeignPtr` `fp`, the memory managed by that pointer lives forever as well. You can free the result of a wrapper explicitly with [http://hackage.haskell.org/package/base-4.8.0.0/docs/Foreign- Ptr.html#v:freeHaskellFunPtr freeHaskellFunPtr]. If you add such a call to your program, say, after the `threadDelay`, then the 30 megabyte object does get freed. Please reopen if I am missing some subtlety here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 05:03:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 05:03:07 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.38a9afb9fce37012d801c288d540c5f4@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: Just found this via a libraries archive discussion. I think there are subtle cases here, if a `..` wildcard is used (possibly a fishy thing in itself). With the `return` example, this is fine: {{{ import Control.Monad (Monad(..), return) }}} This is fine ''provided'' `return` is not used or re-exported, including implicitly: {{{ import Control.Monad (Monad(..)) }}} This is fine if the corresponding import is fine: {{{ module Test (Monad(..), return) where }}} This is definitely wrong: {{{ module Test (Monad(..)) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 07:37:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 07:37:45 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.619e9ba0138b72e9f3abb410ff4a30ab@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): I?ll simply apply the patch to the Debian package and upload to Debian experimental. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 08:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 08:15:18 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.81da37b5af11c66f8d273350a4b1d7ef@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): What is the status of this? Stable interfaces are important for distributions like Debian! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 08:20:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 08:20:44 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.d087cab7952a3b38143574ce08a1beeb@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => high Comment: Also, from reading the patch, it is not clear to me if the filename is also part of the ABI hash. It should not be, as build directory names may change, e.g. on automatic build machines. Also see http://bugs.debian.org/785282 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 08:27:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 08:27:29 -0000 Subject: [GHC] #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) In-Reply-To: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> References: <042.8c875b007562b5496ccd54f67f38dc39@haskell.org> Message-ID: <057.043cf6b8d9e65a46ea14a1eb8c0e0013@haskell.org> #8144: Interface hashes include time stamp of dependent files (UsageFile mtime) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: testcase Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: high => normal Comment: Ah, wait: This is only waiting for a test case, right? So then why do I still see this {{{ ./usr/lib/ghc/base-4.7.0.2/System/Info.hi --- /dev/fd/63 2015-05-14 10:15:20.278404032 +0200 +++ /dev/fd/62 2015-05-14 10:15:20.278404032 +0200 @@ -5,7 +5,7 @@ Way: Wanted [], got [] interface base:System.Info 7084 - interface hash: 038b3a2a32cd43c6a82b096e3ef5c665 + interface hash: 4ff1db7940716ca0e906d3f6b7af1166 ABI hash: 67cae6f933216805d975ee28cd5ea72d export-list hash: 89e8b7a3bfc33bdb505eb586ca9fe64e orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e @@ -64,7 +64,7 @@ divMod e11d60a38cd49de2f6058cc39227517a import safe Prelude 74043f272d60acec1777d3461cfe5ef4 exports: be888345b248b32ace8f805dd49f3def -addDependentFile "/build/ghc-LIQtDg/ghc-7.8.4/includes/ghcplatform.h" +addDependentFile "/build/ghc-Na5lKv/ghc-7.8.4/includes/ghcplatform.h" addDependentFile "libraries/base/dist- install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" f85496685a82c42827c38c1ecec0b5fd }}} Looks like the filename is included in the hash then, because the files are identical in both builds... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 09:15:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 09:15:15 -0000 Subject: [GHC] #10415: ForeignPtr touched in FFI wrapper is never discarded In-Reply-To: <047.76bac1b4c37897ce4c2d32d79bc5296f@haskell.org> References: <047.76bac1b4c37897ce4c2d32d79bc5296f@haskell.org> Message-ID: <062.2dd36cbcd6667c435f319e9cafefec57@haskell.org> #10415: ForeignPtr touched in FFI wrapper is never discarded -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Deewiant): No, you're absolutely right. I suspected that the compiler couldn't reasonably do anything here due to the danger of the wrapper being "squirreled away" as you say. :-) What I thought might be possible is some sort of proof based on things like: 1. In the example, the wrapper is immediately discarded, so there's no need for it to live at all, really. 2. Perhaps a "safe" foreign call is only made immediately next to the wrapper allocation and the wrapper is not referenced elsewhere, so the compiler could see where its lifetime ends. But I didn't realize that the wrappers are functions that require manual freeing! `freeHaskellFunPtr` is something I was missing entirely. I was looking in the FFI sections of the Haskell 2010 report to see if there was anything like that for freeing wrapper functions, but apparently I should've looked elsewhere too. Thanks, and sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 10:48:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 10:48:03 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images Message-ID: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The page https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof- heap.html References an image https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof_scc which does not render. This URL does render though: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/prof_scc.png -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 15:20:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 15:20:20 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) Message-ID: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The nub of the problem looks like this. We have a RULE: {{{#!hs {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} and some core code that looks like: {{{#!hs failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that the rule would match here but clearly it does not. There's obviously a few things in the way of a straightforward match: 1. the key subterm is floated out 2. there's a `\ @ ->` type lambda in the way in the subterm 3. there's a `cast` in the way in the subterm It appears that the problem is not the cast but the combination of 1 & 2. A reduced example shows the problem occurs with just the first two. That said, the real code would also rely on it working with the `cast`. ---- The rest of this is the code needed to construct the example. The code is also attached to the ticket. {{{#!hs {-# LANGUAGE GADTs, RankNTypes, TypeOperators, ScopedTypeVariables, TypeFamilies, KindSignatures, DataKinds, UndecidableInstances #-} module RulesExample (working_example2) where import Prelude hiding (pure, (<*>)) data Decoder s s' where -- explicit encoding of sequencing Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c -- primitive operation in "chained" style ConsumeWord :: Decoder (Word :*: s) s' -> Decoder s s' AlterStack :: (a -> b) -> Decoder b s' -> Decoder a s' data a :*: b = a :*: b infixr 5 :*: }}} We compose actions using the explicit encoding of sequencing {{{#!hs a >>> b = Sequence a b }}} Aside: in the real thing we go via the category class: instance Category Decoder where id = Done a . b = Sequence b a {-# INLINE (.) #-} the Category module defines >>> as flip (.) Now our primitives are in the chained style, and we turn them into the explicit sequencing style by chaining them with Done: {{{#!hs consumeWord :: Decoder s (Word :*: s) consumeWord = ConsumeWord Done alter :: (a -> b) -> Decoder a b alter f = AlterStack f Done }}} example of explicit sequencing: {{{ consumeWord >>> consumeWord >>> ... }}} but naively this will give us things like: {{{ ConsumeWord Done `Sequence` ConsumeWord Done `Sequence` ... }}} and we can interpret this much faster if it's in the "chained" style {{{ ConsumeWord (ConsumeWord (... ) ) }}} Aside: there are good reasons not to just try and construct this chained style in the first place. We can't do it everywhere, and where it would fail we would get bad code. Rather we want to start with something ok and optimise it locally. So, we use RULES to reassociate things and eliminate the Sequence and Done where possible: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} {-# RULES "Sequence/ConsumeWord" forall sa sa'. Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') #-} {-# RULES "Sequence/AlterStack" forall f sa sa'. Sequence (AlterStack f sa) sa' = AlterStack f (Sequence sa sa') #-} }}} Now for starters, ghc produces warnings for all three RULES like: {{{ Rule "Sequence/Done" may never fire because ?RulesExample.Sequence? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?RulesExample.Sequence? }}} but it's currently syntactically invalid to write such a pragma: {{{ {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} and also, the warning isn't wholly correct, the rule can fire: {{{#!hs working_example = consumeWord >>> consumeWord >>> alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} actually, this isn't yet quite enough because we cannot persuade ghc to inline consumeWord, because it's just a static composition of constructors, not even if we hit it with the INLINE pragma: {{{#!hs {-# INLINE consumeWord #-} }}} we have to resort to the bigger hammer of an inline rule: {{{#!hs {-# RULES "inline consumeWord" consumeWord = ConsumeWord Done #-} }}} now this is good, we get exactly the core that we want: {{{ $WDone = \ @ s_anC -> Done @~ _N working_example3 = \ @ b_aw2 ds_dAY -> case ds_dAY of _ { :*: a_aoc ds1_dAZ -> case ds1_dAZ of _ { :*: b1_aod s_aoe -> :*: (a_aoc, b1_aod) s_aoe } } working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) working_example1 = \ @ b_aw2 -> ConsumeWord (working_example2) working_example = \ @ b_aw2 -> ConsumeWord (working_example1) }}} This is perfect. Each constructor is statically allocated and refers to the next one in the chain. This allows the interpreter to walk over this without triggering any allocation, and the chain style means that in the usual case it doesn't have to do control flow call/return work for the Sequence/Done. Note already that we may have an issue with rule matching on Done, since it does get changed later into $WDone. So it could actually be useful to be able to write: {{{ {-# INLINE [0] Done #-} }}} Ok, so, what doesn't work... Floating things out is not itself a problem, this still works fine, the rules fire. So apparently the `\ @ b_aw2 -> ` type abstraction isn't a problem for the rule matching. {{{#!hs second_example = consumeWord >>> part2 part2 = consumeWord >>> part3 part3 = alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} However the following fails to work. This example is actually extracted from the core of a real example that doesn't work. {{{#!hs artificial_example = Sequence failing_example3 failing_example1 where failing_example3 = Sequence failing_example5 failing_example4 failing_example5 = Sequence Done failing_example6 failing_example6 = ConsumeWord Done failing_example4 = ConsumeWord Done failing_example1 = AlterStack failing_example2 Done failing_example2 (a :*: b :*: s) = (a,b) :*: s }}} here's a specific example of a rule not matching: {{{ ailing_example3 = \ @ a_ax3 -> Sequence (failing_example4) (failing_example4) failing_example4 = \ @ s_awp -> ConsumeWord ($WDone) }}} This should match the rule {{{ Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') }}} but apparently does not. The combo of the floating out and the type lambda seem to get in the way. Note that in this example ghc has also CSE'd the failing_example4 with failing_example5 and so failing_example4 is used twice. But if that's the problem here, there also equivalent instances of the Sequence/Sequence rule not matching. Also, ConsumeWord is certainly CONLIKE so we'd hope even if ghc had already CSEd that it'd allow the duplication for the rule matching. In fact looking at the simpl iterations I think the rule would have gotten a chance to fire before the CSE occured. In the real example that the above was extracted from we also have `cast`s in the way. Unfortunately we need more infrastructure to illustrate the full example. I don't think the details of this infrastructure is important, except that it ends up giving us `cast` in the core. We're building an abstraction on top of Decoder to let us use Applicative style. {{{#!hs data Fun a = Id | Cons a | O (Fun a) (Fun a) -- this requires UndecidableInstances type family Apply (f :: Fun *) (a :: *) :: * type instance Apply Id a = a type instance Apply (Cons x) a = x :*: a type instance Apply (O f g) a = Apply f (Apply g a) }}} we pair up stack changes and their inverses {{{#!hs data DecoderA0 s (f :: Fun *) a = DecoderA0 (Decoder s (Apply f s)) -- change the stack from s -> f s (Apply f s -> (s, a)) -- change stack back from f s -> s {-# INLINE pure0 #-} pure0 :: forall a s. a -> DecoderA0 s Id a pure0 a = DecoderA0 Done (\s -> (s, a)) {-# INLINE app0 #-} app0 :: DecoderA0 s f (a -> b) -> DecoderA0 (Apply f s) g a -> DecoderA0 s (g `O` f) b app0 (DecoderA0 d f) (DecoderA0 d' x) = DecoderA0 (d >>> d') appStack where -- just flipped <*> for state monad appStack = \s -> case x s of (s', x') -> case f s' of (s'', f') -> (s'', f' x') {-# INLINE close0 #-} close0 :: forall s f a. DecoderA0 s f a -> Decoder s (a :*: s) close0 (DecoderA0 d se) = d >>> alter se' where se' :: Apply f s -> (a :*: s) se' s = case se s of (s', a) -> a :*: s' }}} now we can abstract over the stack change, because it always takes us back to the same initial stack state {{{#!hs data DecoderA a where DecoderA :: (forall s. DecoderA0 s f a) -> DecoderA a }}} in the real thing we use Functor and Applicative instances, but we only need bits {{{#!hs pure a = DecoderA (pure0 a) DecoderA f <*> DecoderA x = DecoderA (app0 f x) infixl 4 <*> }}} now conversions functions: {{{#!hs {-# INLINE embedDecoderA #-} embedDecoderA :: DecoderA a -> Decoder s (a :*: s) embedDecoderA (DecoderA ap) = close0 ap {-# INLINE[1] embedDecoder #-} embedDecoder :: forall a. (forall s. Decoder s (a :*: s)) -> DecoderA a embedDecoder dec = DecoderA popResultAp where popResultAp :: DecoderA0 s (Cons a) a popResultAp = DecoderA0 dec (\(a :*: s) -> (s, a)) }}} ok, we can finally build our example... {{{#!hs failing_example = embedDecoderA $ pure (,) <*> embedDecoder consumeWord <*> embedDecoder consumeWord }}} So all the applicative stuff gets inlined away, but we end up with this core: {{{ $WDone = \ @ s_anC -> Done @~ _N failing_example6 = \ @ s_azo -> ConsumeWord ($WDone) failing_example4 = \ @ s_azo -> ConsumeWord ($WDone) failing_example5 = \ @ s_azo -> Sequence (($WDone) `cast` ...) ((failing_example6) `cast` ...) failing_example3 = \ @ s_azo -> Sequence ((failing_example5) `cast` ...) ((failing_example4) `cast` ...) failing_example2 = \ @ s_azo s1_aox -> case s1_aox `cast` ... of _ { :*: a_aoH s2_aoI -> case s2_aoI `cast` ... of _ { :*: a1_Xpa s3_Xpc -> :*: (a1_Xpa, a_aoH) (s3_Xpc `cast` ...) } } failing_example1 = \ @ s_azo -> AlterStack (failing_example2) ($WDone) failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (failing_example1) }}} We have two examples of RULES not mathing where we would have hoped. Firstly, we have: {{{ Sequence (($WDone) `cast` ...) (...) }}} We would of course hope that the rule Sequence Done sa = sa would match here It's unclear if this is due to the `$WDone` or the `cast`. Certainly the conversion from Done to `$WDone` can be worked around by using a function {{{ {-# INLINE [0] done #-} done = Done }}} and changing the code and rules to use that. So the main problem is the one mentioned at the top of the ticket: {{{ failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that this rule would match {{{ Sequence (Sequence a b) c = Sequence a (Sequence b c) }}} So this is the same issue as in the artificial example but now additionally there's a `cast` in the way in the subterm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 15:31:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 15:31:29 -0000 Subject: [GHC] #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor Message-ID: <045.1fde50eb50f6dee4fad99ec3cf94833c@haskell.org> #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is mentioned in passing in ticket #10417, but pulling it out here to track it. Given a type {{{#!hs data Decoder s s' where Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c }}} and rules: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} GHC gives us warnings like: {{{ Rule "Sequence/Done" may never fire because ?RulesExample.Sequence? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?RulesExample.Sequence? }}} but it's currently syntactically invalid to write such a pragma: {{{#!hs {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} Now there's two problems here: 1. This warning is wrong most of the time 2. The warning is actually right sometimes, but there's nothing you can do about it. For 1, most of the time constructors remain as themselves in core, with no wrappers to get in the way of rule matching. In these cases the warning is just wrong. For 2, for some constructors ghc does rewrite them. In this case the rewrite rule really will fail to match. But we cannot tell GHC to delay the rewriting of them because we cannot write INLINE pragmas for them. So for this case it would be useful to allow us to write INLINE pragmas. In the above example, GHC will rewrite `Done` during optimisation, e.g. an excerpt from ticket #10417: {{{ $WDone = \ @ s_anC -> Done @~ _N working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) }}} This can and will interfere with rule matching. In this case it would be desirable to be able to write {{{ {-# INLINE [0] Done #-} }}} Currently that's a syntax error. For the case of nullary constructors, a workaround is to consistently use a smart constructor with an `INLINE [0]` pragma, and do all the rule matching on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 15:32:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 15:32:40 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) In-Reply-To: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> References: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> Message-ID: <060.65eecfc689f78851335abef63c3a2a41@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by duncan): The issue with the rule/constructor warning is in a separate ticket #10418 for better tracking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 17:49:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 17:49:59 -0000 Subject: [GHC] #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor In-Reply-To: <045.1fde50eb50f6dee4fad99ec3cf94833c@haskell.org> References: <045.1fde50eb50f6dee4fad99ec3cf94833c@haskell.org> Message-ID: <060.addb6e3c4dd5cef09945b07754f909fd@haskell.org> #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 10417, 7398 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by duncan): * related: => 10417, 7398 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 17:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 17:50:42 -0000 Subject: [GHC] #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor In-Reply-To: <045.1fde50eb50f6dee4fad99ec3cf94833c@haskell.org> References: <045.1fde50eb50f6dee4fad99ec3cf94833c@haskell.org> Message-ID: <060.b657e7c155f5b4ed92bd88fbc34aa191@haskell.org> #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10417, #7398 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by duncan): * related: 10417, 7398 => #10417, #7398 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 17:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 17:51:28 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.9739d934db19dd45b98f0239bdc4b359@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by duncan): * related: #6082 => #6082, #10418 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 19:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 19:40:28 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.96f645ee35131eb029a9c1199690da11@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlekseyKliger): I've put together a Gist (by excising code from unbound-generics) that runs into this issue. I've not tried the committed fix yet (don't have a GHC tree around), but perhaps someone else would like to play around with it: https://gist.github.com/lambdageek/c05cd379fe649600070c {{{ $ ghc -c -O Alpha.hs $ ghc -c -v -O Calc.hs # note Calc.hs hangs on "Called arity analysis" }}} To make the compilation take longer, add some more branches to the Expr datatype - Generics are pretty good for building giant blobs of mutually recursive functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 21:26:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 21:26:01 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.38158102824ed96455dc25778a1ba9ca@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" Revert multiple commits This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 21:26:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 21:26:01 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.c167a0e2c7cfa693ba54d71bf60bee9d@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" Revert multiple commits This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 21:26:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 21:26:01 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.0308ef437344c996e54cea6a1eef546a@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | perf/should_run/T10359 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" Revert multiple commits This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 14 22:34:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 May 2015 22:34:44 -0000 Subject: [GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT Message-ID: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, making a call to `loadSysInterface` (or the related interfaces) has two effects: 1. You get a `ModIface` 2. The declarations/instances/etc of the interface are type-checked and loaded into the EPT In fact, users of these functions rarely want both of these; they either only want the `ModIface`, or only want to load up the declarations. Here is a survey I did, where `I` indicates a `ModIface` was wanted, `D` indicates we wanted to load the declarations, and `ID` means both were wanted; {{{ RnSplice loadInterfaceForName: D rnBracket: deprecation checking of identifiers in brackets () RnEnv loadInterfaceForName I warnIfDeprecated: deprecation checking of GlobalRdrElt (mi_warn_fun) I lookupFixityRn: fixity lookup (mi_fix_fun) loadSrcInterface_maybe ID lookupQualifiedNameGHCi: implicit import RnNames loadSrcInterface ID rnImportDecl: source import! $$$$$ I printMinimalImports: minimal import calculation (mi_exports) DsMonad loadInterface I loadModule: load and return exported entities (like a source import but for Module) special case for Data.Array.Parallel DynamicLoading loadPluginInterface D forceLoadModuleInterfaces: what. Linker loadInterface I getLinkDeps: poke the dependencies (mi_boot, mi_deps) loadUserInterface I random ass thing to check if it's a sigof XXX (mi_sig_of) MkIface loadInterface I? needInterface: utility checkModUsage: given the usage information from the old hi, determine if recompilation is required (hashes only) FamInst loadSysInterface D getFamInsts: load instance into EPS and return it TcDeriv loadInterfaceForName I getDataConFixityFun: looks at mi_fix_fn TcRnDriver loadSysInterface I tcRnSignature: signature renaming hack D loadUnqualIfaces: for accurate available instance reporting loadModuleInterfaces D tcRnImports: load orphans loadModuleInterface getModuleInterface: load a 'Module' (GHCi) D hscCheckSafe' (HscMain, mi_trust, mi_trust_pkg, mi_deps) ID getPackageModuleInfo (contains interface) loadSrcInterface D runTcInteractive: mi_deps/dep_orphs, pull in orphans from interactive context ic_imports TcSplice loadInterfaceForModule I reifyModule: mi_usages only }}} It's well worth noting that for most `Name`s, it is NOT NECESSARY, since when we pull on it with `loadDecl`, the interface will get loaded in. Consequently, I think some of the cases where we're loading interfaces are unnecessary, e.g. the case in `rnBracket`. The primary cases are dealing with orphan imports; there are multiple sites which redo this logic, and it should all be centralized in one place. So here is the concrete proposal: * Add a new function for taking a `ModIface` and loading it into the EPT. * Change the rest of the existing `loadXXXInterface` functions to NOT load declarations. We'll actually typecheck the interface file when we pull on the `Name` in question during type checking. * Introduce a new function to `LoadIface` for loading orphans (i.e. what to do when a source level import occurs). Have `lookupQualifiedNameGHCi`, `rnImportDecl`, `tcRnImports` and `runTcInteractive` use this function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 08:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 08:48:31 -0000 Subject: [GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT In-Reply-To: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> References: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> Message-ID: <060.fc73220e3e6a31e04935febb9363203c@haskell.org> #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. Note that * If you want a declaration you have to load the `ModIface`, and we don't want to do that twice, so D implies I. * If you want the `ModIface` it's not much work to load all the declarations because we typecheck them lazily (via `forkM` in `TcIface`). So it's not clear to me that you are going to save much work. So: what's your goal here? Just efficiency? The proposal would mean that in the `ExternalPackageState` there might be members of the `eps_PIT` whose declarations have not been typechecked and loaded into the `eps_PTE`. Currently it's an invariant that they all are. That might be fine but it needs documenting. Here just for reference is the current defn of EPS: {{{ data ExternalPackageState = EPS { eps_is_boot :: !(ModuleNameEnv (ModuleName, IsBootInterface)), eps_PIT :: !PackageIfaceTable, eps_PTE :: !PackageTypeEnv, eps_inst_env :: !PackageInstEnv, eps_fam_inst_env :: !PackageFamInstEnv, eps_rule_base :: !PackageRuleBase, eps_vect_info :: !PackageVectInfo, eps_ann_env :: !PackageAnnEnv, eps_mod_fam_inst_env :: !(ModuleEnv FamInstEnv), eps_stats :: !EpsStats } }}} Thinking about the invariant leads to some questions: * Consider a module whose `ModIface` M we have loaded, into the `eps_PIT`. Now suppose we want the declaration for `M.foo`. Do we:[[BR]][[BR]] 1. Find `foo`'s `IfaceDecl` in M's `ModIface` and add that declaration alone to `eps_PTE`? But how do we find `foo`'s `IfaceDecl`, remembering that one `IfaceDecl` may bind many `Name`s.? You'll need to build a little index; but that is (in effect) what the `eps_PTE` already is! [[BR]][[BR]] 2. Typecheck all the declarations in M's `ModIface` and add all of them to the `eps_PTE`? If so, how do we record that we have done this so we don't repeat it? Maybe it's enough that future lookups will find `M.foo` in the PTE. * Currently we assume that if we've loaded an interface for a non-orphan module we've loaded its instances into `eps_inst_env`. But that won't be true any more. Or will it? * Similarly we'd have to think about `eps_ann_env`, `eps_mod_fam_inst_env` etc. So currently I'm unconvinced. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 09:00:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 09:00:55 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.ecd63d8fa73424daa227ef43b7633328@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high Comment: George Colpitts asks: the milestone is 7.12.1, should it be 7.10.2? It would be unusual to delay a patch-level release for a ticket that has been open for five years. Doing so would mean indefinitely delaying 7.10.2. By ?indefinite? I don't mean "forever", I just mean ?we don?t know how long?: * We don?t have anyone owning the ticket, * we don?t know how difficult it is to fix; and * a full bulletproof fix is probably quite challenging (e.g. forcing the unique-supply generator to give reproducible results even though some (ultimately irrelevant) bits of the environment have changes, would be difficult) At the same time we have some folk urging us to get 7.10.2 out sooner rather than later. So everyone: * If you think we should delay 7.10.2 pending at least some progress on this, please say so on the ticket. * Better still, roll up your sleeves and take a crack at understanding more precisely what is going on, and proposing a fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 09:37:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 09:37:15 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.850659dd481b1d416dc8621f776a8fb0@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I agree that this should not hold up a patch level release that others are waiting for. Better fix this properly, and then, maybe, see if it can be part of a 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 10:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 10:48:31 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.e0a7f21b3b02d67f27bbe7d114bd24b2@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @ezyang: I absolutely agree. Parallelism within a single process is always going to be harder to scale than separate processes. That said, there might still be low-hanging fruit (e.g. better default heap settings) for parallel compilation. I very much like `-j` in GHCi though - we cut the time to load a large project by 3x just by turning on `-j` in GHCi with some suitable heap settings (`-A256m`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 14:20:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 14:20:30 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.379b9b2fa6334143fd3acdaf596f04e6@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): If an ord instance can be defined sensibly, perhaps on a new type wrapping of that block skeleton, I'd be in favor of that. It doesn't have to be a canonical ordering, merely a valid total ordering living on a new type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 14:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 14:31:19 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.c12ed0c37a9d9d1845e4691028807986@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Maybe the blocks could be grouped not by hash, but rather by block they might possible jump to. Then for each block B one only needs to compare the blocks that can jump to B. When identical blocks are found, the corresponding may-jump-to-sets can simply be unioned. OTOH, this seems relatively obvious, so there must be a reason why it is not done this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 16:41:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 16:41:06 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) In-Reply-To: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> References: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> Message-ID: <060.a1f84fb4786baa4a4d8e62d8b51c7e95@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > The nub of the problem looks like this. We have a RULE: > > {{{#!hs > {-# RULES "Sequence/Sequence" > forall a b c. Sequence (Sequence a b) c > = Sequence a (Sequence b c) > #-} > }}} > and some core code that looks like: > {{{#!hs > failing_example = > \ @ s_azo -> > Sequence ((failing_example3) `cast` ...) (...) > > failing_example3 = > \ @ s_azo -> > Sequence (...) (...) > }}} > We would hope that the rule would match here but clearly it does not. > There's obviously a few things in the way of a straightforward match: > > 1. the key subterm is floated out > 2. there's a `\ @ ->` type lambda in the way in the subterm > 3. there's a `cast` in the way in the subterm > > It appears that the problem is not the cast but the combination of 1 & 2. > A reduced example shows the problem occurs with just the first two. That > said, the real code would also rely on it working with the `cast`. > > ---- > > The rest of this is the code needed to construct the example. The code is > also attached to the ticket. > > {{{#!hs > {-# LANGUAGE GADTs, RankNTypes, TypeOperators, ScopedTypeVariables, > TypeFamilies, KindSignatures, DataKinds, > UndecidableInstances #-} > > module RulesExample (working_example2) where > > import Prelude hiding (pure, (<*>)) > > data Decoder s s' where > > -- explicit encoding of sequencing > > Done :: Decoder s s > Sequence :: Decoder a b -> Decoder b c -> Decoder a c > > -- primitive operation in "chained" style > > ConsumeWord :: Decoder (Word :*: s) s' -> Decoder s s' > AlterStack :: (a -> b) -> Decoder b s' -> Decoder a s' > > data a :*: b = a :*: b > infixr 5 :*: > }}} > We compose actions using the explicit encoding of sequencing > {{{#!hs > a >>> b = Sequence a b > }}} > Aside: in the real thing we go via the category class: > > instance Category Decoder where > id = Done > a . b = Sequence b a > {-# INLINE (.) #-} > > the Category module defines >>> as flip (.) > > Now our primitives are in the chained style, and we turn them into the > explicit sequencing style by chaining them with Done: > > {{{#!hs > consumeWord :: Decoder s (Word :*: s) > consumeWord = ConsumeWord Done > > alter :: (a -> b) -> Decoder a b > alter f = AlterStack f Done > }}} > example of explicit sequencing: > {{{ > consumeWord >>> consumeWord >>> ... > }}} > but naively this will give us things like: > {{{ > ConsumeWord Done `Sequence` ConsumeWord Done `Sequence` ... > }}} > and we can interpret this much faster if it's in the "chained" style > {{{ > ConsumeWord (ConsumeWord (... ) ) > }}} > Aside: there are good reasons not to just try and construct this chained > style in the first place. We can't do it everywhere, and where it would > fail we would get bad code. Rather we want to start with something ok and > optimise it locally. > > So, we use RULES to reassociate things and eliminate the Sequence and > Done where possible: > {{{#!hs > {-# RULES "Sequence/Done" > forall sa. Sequence Done sa = sa > #-} > > {-# RULES "Sequence/Sequence" > forall a b c. Sequence (Sequence a b) c > = Sequence a (Sequence b c) > #-} > > {-# RULES "Sequence/ConsumeWord" > forall sa sa'. Sequence (ConsumeWord sa) sa' > = ConsumeWord (Sequence sa sa') > #-} > > {-# RULES "Sequence/AlterStack" > forall f sa sa'. Sequence (AlterStack f sa) sa' > = AlterStack f (Sequence sa sa') > #-} > }}} > Now for starters, ghc produces warnings for all three RULES like: > {{{ > Rule "Sequence/Done" may never fire > because ?RulesExample.Sequence? might inline first > Probable fix: add an INLINE[n] or NOINLINE[n] pragma on > ?RulesExample.Sequence? > }}} > but it's currently syntactically invalid to write such a pragma: > {{{ > {-# INLINE [0] Done #-} > {-# INLINE [0] Sequence #-} > }}} > and also, the warning isn't wholly correct, the rule can fire: > {{{#!hs > working_example = consumeWord >>> consumeWord > >>> alter (\(a :*: b :*: s) -> (a,b) :*: s) > > }}} > actually, this isn't yet quite enough because we cannot persuade ghc to > inline consumeWord, because it's just a static composition of > constructors, not even if we hit it with the INLINE pragma: > {{{#!hs > {-# INLINE consumeWord #-} > }}} > we have to resort to the bigger hammer of an inline rule: > {{{#!hs > {-# RULES "inline consumeWord" consumeWord = ConsumeWord Done #-} > }}} > now this is good, we get exactly the core that we want: > {{{ > $WDone = \ @ s_anC -> Done @~ _N > > working_example3 = > \ @ b_aw2 ds_dAY -> > case ds_dAY of _ { :*: a_aoc ds1_dAZ -> > case ds1_dAZ of _ { :*: b1_aod s_aoe -> :*: (a_aoc, b1_aod) s_aoe } > } > > working_example2 = > \ @ b_aw2 -> AlterStack (working_example3) ($WDone) > > working_example1 = \ @ b_aw2 -> ConsumeWord (working_example2) > > working_example = \ @ b_aw2 -> ConsumeWord (working_example1) > }}} > This is perfect. Each constructor is statically allocated and refers to > the next one in the chain. This allows the interpreter to walk over this > without triggering any allocation, and the chain style means that in the > usual case it doesn't have to do control flow call/return work for the > Sequence/Done. > > Note already that we may have an issue with rule matching on Done, since > it does get changed later into $WDone. So it could actually be useful to > be able > to write: > {{{ > {-# INLINE [0] Done #-} > }}} > Ok, so, what doesn't work... > > Floating things out is not itself a problem, this still works fine, the > rules fire. So apparently the `\ @ b_aw2 -> ` type abstraction isn't a > problem for the rule matching. > {{{#!hs > second_example = consumeWord >>> part2 > > part2 = consumeWord >>> part3 > > part3 = alter (\(a :*: b :*: s) -> (a,b) :*: s) > }}} > However the following fails to work. This example is actually extracted > from the core of a real example that doesn't work. > {{{#!hs > artificial_example = Sequence failing_example3 failing_example1 > where > failing_example3 = Sequence failing_example5 failing_example4 > failing_example5 = Sequence Done failing_example6 > failing_example6 = ConsumeWord Done > failing_example4 = ConsumeWord Done > failing_example1 = AlterStack failing_example2 Done > failing_example2 (a :*: b :*: s) = (a,b) :*: s > }}} > here's a specific example of a rule not matching: > {{{ > ailing_example3 = > \ @ a_ax3 -> > Sequence > (failing_example4) (failing_example4) > > failing_example4 = > \ @ s_awp -> ConsumeWord ($WDone) > }}} > This should match the rule > {{{ > Sequence (ConsumeWord sa) sa' > = ConsumeWord (Sequence sa sa') > }}} > but apparently does not. The combo of the floating out and the type > lambda seem to get in the way. Note that in this example ghc has also > CSE'd the failing_example4 with failing_example5 and so failing_example4 > is used twice. > > But if that's the problem here, there also equivalent instances of the > Sequence/Sequence rule not matching. Also, ConsumeWord is certainly > CONLIKE so we'd hope even if ghc had already CSEd that it'd allow the > duplication for the rule matching. In fact looking at the simpl > iterations I think the > rule would have gotten a chance to fire before the CSE occured. > > In the real example that the above was extracted from we also have > `cast`s in the way. > > Unfortunately we need more infrastructure to illustrate the full example. > I don't think the details of this infrastructure is important, except > that it ends up giving us `cast` in the core. > > We're building an abstraction on top of Decoder to let us use Applicative > style. > {{{#!hs > data Fun a = Id > | Cons a > | O (Fun a) (Fun a) > > -- this requires UndecidableInstances > type family Apply (f :: Fun *) (a :: *) :: * > type instance Apply Id a = a > type instance Apply (Cons x) a = x :*: a > type instance Apply (O f g) a = Apply f (Apply g a) > }}} > we pair up stack changes and their inverses > {{{#!hs > data DecoderA0 s (f :: Fun *) a > = DecoderA0 (Decoder s (Apply f s)) -- change the stack from s -> > f s > (Apply f s -> (s, a)) -- change stack back from f s > -> s > > {-# INLINE pure0 #-} > pure0 :: forall a s. a -> DecoderA0 s Id a > pure0 a = DecoderA0 Done (\s -> (s, a)) > > {-# INLINE app0 #-} > app0 :: DecoderA0 s f (a -> b) -> DecoderA0 (Apply f s) g a -> DecoderA0 > s (g `O` f) b > app0 (DecoderA0 d f) (DecoderA0 d' x) = > DecoderA0 (d >>> d') appStack > where > -- just flipped <*> for state monad > appStack = \s -> case x s of > (s', x') -> case f s' of > (s'', f') -> (s'', f' x') > > {-# INLINE close0 #-} > close0 :: forall s f a. DecoderA0 s f a -> Decoder s (a :*: s) > close0 (DecoderA0 d se) = d >>> alter se' > where > se' :: Apply f s -> (a :*: s) > se' s = case se s of (s', a) -> a :*: s' > }}} > now we can abstract over the stack change, because it always takes us > back to the same initial stack state > {{{#!hs > data DecoderA a where > DecoderA :: (forall s. DecoderA0 s f a) -> DecoderA a > }}} > in the real thing we use Functor and Applicative instances, but we only > need bits > {{{#!hs > pure a = DecoderA (pure0 a) > DecoderA f <*> DecoderA x = DecoderA (app0 f x) > > infixl 4 <*> > }}} > now conversions functions: > {{{#!hs > {-# INLINE embedDecoderA #-} > embedDecoderA :: DecoderA a -> Decoder s (a :*: s) > embedDecoderA (DecoderA ap) = close0 ap > > {-# INLINE[1] embedDecoder #-} > embedDecoder :: forall a. (forall s. Decoder s (a :*: s)) -> DecoderA a > embedDecoder dec = > DecoderA popResultAp > where > popResultAp :: DecoderA0 s (Cons a) a > popResultAp = DecoderA0 dec (\(a :*: s) -> (s, a)) > }}} > ok, we can finally build our example... > {{{#!hs > failing_example = > embedDecoderA $ > pure (,) <*> embedDecoder consumeWord > <*> embedDecoder consumeWord > }}} > So all the applicative stuff gets inlined away, but we end up with this > core: > {{{ > $WDone = \ @ s_anC -> Done @~ _N > > failing_example6 = \ @ s_azo -> ConsumeWord ($WDone) > > failing_example4 = \ @ s_azo -> ConsumeWord ($WDone) > > failing_example5 = > \ @ s_azo -> > Sequence (($WDone) `cast` ...) ((failing_example6) `cast` ...) > > failing_example3 = > \ @ s_azo -> > Sequence > ((failing_example5) `cast` ...) ((failing_example4) `cast` ...) > > failing_example2 = > \ @ s_azo s1_aox -> > case s1_aox `cast` ... of _ { :*: a_aoH s2_aoI -> > case s2_aoI `cast` ... of _ { :*: a1_Xpa s3_Xpc -> > :*: (a1_Xpa, a_aoH) (s3_Xpc `cast` ...) > } > } > > failing_example1 = > \ @ s_azo -> AlterStack (failing_example2) ($WDone) > > failing_example = > \ @ s_azo -> > Sequence ((failing_example3) `cast` ...) (failing_example1) > }}} > We have two examples of RULES not mathing where we would have hoped. > > Firstly, we have: > {{{ > Sequence (($WDone) `cast` ...) (...) > }}} > We would of course hope that the rule Sequence Done sa = sa would match > here > > It's unclear if this is due to the `$WDone` or the `cast`. Certainly the > conversion from Done to `$WDone` can be worked around by using a function > {{{ > {-# INLINE [0] done #-} > done = Done > }}} > and changing the code and rules to use that. > > So the main problem is the one mentioned at the top of the ticket: > {{{ > failing_example = > \ @ s_azo -> > Sequence ((failing_example3) `cast` ...) (...) > > failing_example3 = > \ @ s_azo -> > Sequence (...) (...) > }}} > We would hope that this rule would match > {{{ > Sequence (Sequence a b) c = Sequence a (Sequence b c) > }}} > So this is the same issue as in the artificial example but now > additionally there's a `cast` in the way in the subterm. New description: The nub of the problem looks like this. We have a RULE: {{{#!hs {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} and some core code that looks like: {{{#!hs failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that the rule would match here but clearly it does not. There's obviously a few things in the way of a straightforward match: 1. the key subterm is floated out 2. there's a `\ @ ->` type lambda in the way in the subterm 3. there's a `cast` in the way in the subterm It appears that the problem is not the cast but the combination of 1 & 2. A reduced example shows the problem occurs with just the first two. That said, the real code would also rely on it working with the `cast`. ---- The rest of this is the code needed to construct the example. The code is also attached to the ticket. {{{#!hs {-# LANGUAGE GADTs, RankNTypes, TypeOperators, ScopedTypeVariables, TypeFamilies, KindSignatures, DataKinds, UndecidableInstances #-} module RulesExample (working_example2) where import Prelude hiding (pure, (<*>)) data Decoder s s' where -- explicit encoding of sequencing Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c -- primitive operation in "chained" style ConsumeWord :: Decoder (Word :*: s) s' -> Decoder s s' AlterStack :: (a -> b) -> Decoder b s' -> Decoder a s' data a :*: b = a :*: b infixr 5 :*: }}} We compose actions using the explicit encoding of sequencing {{{#!hs a >>> b = Sequence a b }}} Aside: in the real thing we go via the category class: {{{ instance Category Decoder where id = Done a . b = Sequence b a {-# INLINE (.) #-} }}} The Category module defines `>>>` as `flip (.)` Now our primitives are in the chained style, and we turn them into the explicit sequencing style by chaining them with Done: {{{#!hs consumeWord :: Decoder s (Word :*: s) consumeWord = ConsumeWord Done alter :: (a -> b) -> Decoder a b alter f = AlterStack f Done }}} example of explicit sequencing: {{{ consumeWord >>> consumeWord >>> ... }}} but naively this will give us things like: {{{ ConsumeWord Done `Sequence` ConsumeWord Done `Sequence` ... }}} and we can interpret this much faster if it's in the "chained" style {{{ ConsumeWord (ConsumeWord (... ) ) }}} Aside: there are good reasons not to just try and construct this chained style in the first place. We can't do it everywhere, and where it would fail we would get bad code. Rather we want to start with something ok and optimise it locally. So, we use RULES to reassociate things and eliminate the Sequence and Done where possible: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} {-# RULES "Sequence/ConsumeWord" forall sa sa'. Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') #-} {-# RULES "Sequence/AlterStack" forall f sa sa'. Sequence (AlterStack f sa) sa' = AlterStack f (Sequence sa sa') #-} }}} Now for starters, ghc produces warnings for all three RULES like: {{{ Rule "Sequence/Done" may never fire because ?RulesExample.Sequence? might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ?RulesExample.Sequence? }}} but it's currently syntactically invalid to write such a pragma: {{{ {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} and also, the warning isn't wholly correct, the rule can fire: {{{#!hs working_example = consumeWord >>> consumeWord >>> alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} actually, this isn't yet quite enough because we cannot persuade ghc to inline consumeWord, because it's just a static composition of constructors, not even if we hit it with the INLINE pragma: {{{#!hs {-# INLINE consumeWord #-} }}} we have to resort to the bigger hammer of an inline rule: {{{#!hs {-# RULES "inline consumeWord" consumeWord = ConsumeWord Done #-} }}} now this is good, we get exactly the core that we want: {{{ $WDone = \ @ s_anC -> Done @~ _N working_example3 = \ @ b_aw2 ds_dAY -> case ds_dAY of _ { :*: a_aoc ds1_dAZ -> case ds1_dAZ of _ { :*: b1_aod s_aoe -> :*: (a_aoc, b1_aod) s_aoe } } working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) working_example1 = \ @ b_aw2 -> ConsumeWord (working_example2) working_example = \ @ b_aw2 -> ConsumeWord (working_example1) }}} This is perfect. Each constructor is statically allocated and refers to the next one in the chain. This allows the interpreter to walk over this without triggering any allocation, and the chain style means that in the usual case it doesn't have to do control flow call/return work for the Sequence/Done. Note already that we may have an issue with rule matching on Done, since it does get changed later into $WDone. So it could actually be useful to be able to write: {{{ {-# INLINE [0] Done #-} }}} Ok, so, what doesn't work... Floating things out is not itself a problem, this still works fine, the rules fire. So apparently the `\ @ b_aw2 -> ` type abstraction isn't a problem for the rule matching. {{{#!hs second_example = consumeWord >>> part2 part2 = consumeWord >>> part3 part3 = alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} However the following fails to work. This example is actually extracted from the core of a real example that doesn't work. {{{#!hs artificial_example = Sequence failing_example3 failing_example1 where failing_example3 = Sequence failing_example5 failing_example4 failing_example5 = Sequence Done failing_example6 failing_example6 = ConsumeWord Done failing_example4 = ConsumeWord Done failing_example1 = AlterStack failing_example2 Done failing_example2 (a :*: b :*: s) = (a,b) :*: s }}} here's a specific example of a rule not matching: {{{ ailing_example3 = \ @ a_ax3 -> Sequence (failing_example4) (failing_example4) failing_example4 = \ @ s_awp -> ConsumeWord ($WDone) }}} This should match the rule {{{ Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') }}} but apparently does not. The combo of the floating out and the type lambda seem to get in the way. Note that in this example ghc has also CSE'd the failing_example4 with failing_example5 and so failing_example4 is used twice. But if that's the problem here, there also equivalent instances of the Sequence/Sequence rule not matching. Also, ConsumeWord is certainly CONLIKE so we'd hope even if ghc had already CSEd that it'd allow the duplication for the rule matching. In fact looking at the simpl iterations I think the rule would have gotten a chance to fire before the CSE occured. In the real example that the above was extracted from we also have `cast`s in the way. Unfortunately we need more infrastructure to illustrate the full example. I don't think the details of this infrastructure is important, except that it ends up giving us `cast` in the core. We're building an abstraction on top of Decoder to let us use Applicative style. {{{#!hs data Fun a = Id | Cons a | O (Fun a) (Fun a) -- this requires UndecidableInstances type family Apply (f :: Fun *) (a :: *) :: * type instance Apply Id a = a type instance Apply (Cons x) a = x :*: a type instance Apply (O f g) a = Apply f (Apply g a) }}} we pair up stack changes and their inverses {{{#!hs data DecoderA0 s (f :: Fun *) a = DecoderA0 (Decoder s (Apply f s)) -- change the stack from s -> f s (Apply f s -> (s, a)) -- change stack back from f s -> s {-# INLINE pure0 #-} pure0 :: forall a s. a -> DecoderA0 s Id a pure0 a = DecoderA0 Done (\s -> (s, a)) {-# INLINE app0 #-} app0 :: DecoderA0 s f (a -> b) -> DecoderA0 (Apply f s) g a -> DecoderA0 s (g `O` f) b app0 (DecoderA0 d f) (DecoderA0 d' x) = DecoderA0 (d >>> d') appStack where -- just flipped <*> for state monad appStack = \s -> case x s of (s', x') -> case f s' of (s'', f') -> (s'', f' x') {-# INLINE close0 #-} close0 :: forall s f a. DecoderA0 s f a -> Decoder s (a :*: s) close0 (DecoderA0 d se) = d >>> alter se' where se' :: Apply f s -> (a :*: s) se' s = case se s of (s', a) -> a :*: s' }}} now we can abstract over the stack change, because it always takes us back to the same initial stack state {{{#!hs data DecoderA a where DecoderA :: (forall s. DecoderA0 s f a) -> DecoderA a }}} in the real thing we use Functor and Applicative instances, but we only need bits {{{#!hs pure a = DecoderA (pure0 a) DecoderA f <*> DecoderA x = DecoderA (app0 f x) infixl 4 <*> }}} now conversions functions: {{{#!hs {-# INLINE embedDecoderA #-} embedDecoderA :: DecoderA a -> Decoder s (a :*: s) embedDecoderA (DecoderA ap) = close0 ap {-# INLINE[1] embedDecoder #-} embedDecoder :: forall a. (forall s. Decoder s (a :*: s)) -> DecoderA a embedDecoder dec = DecoderA popResultAp where popResultAp :: DecoderA0 s (Cons a) a popResultAp = DecoderA0 dec (\(a :*: s) -> (s, a)) }}} ok, we can finally build our example... {{{#!hs failing_example = embedDecoderA $ pure (,) <*> embedDecoder consumeWord <*> embedDecoder consumeWord }}} So all the applicative stuff gets inlined away, but we end up with this core: {{{ $WDone = \ @ s_anC -> Done @~ _N failing_example6 = \ @ s_azo -> ConsumeWord ($WDone) failing_example4 = \ @ s_azo -> ConsumeWord ($WDone) failing_example5 = \ @ s_azo -> Sequence (($WDone) `cast` ...) ((failing_example6) `cast` ...) failing_example3 = \ @ s_azo -> Sequence ((failing_example5) `cast` ...) ((failing_example4) `cast` ...) failing_example2 = \ @ s_azo s1_aox -> case s1_aox `cast` ... of _ { :*: a_aoH s2_aoI -> case s2_aoI `cast` ... of _ { :*: a1_Xpa s3_Xpc -> :*: (a1_Xpa, a_aoH) (s3_Xpc `cast` ...) } } failing_example1 = \ @ s_azo -> AlterStack (failing_example2) ($WDone) failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (failing_example1) }}} We have two examples of RULES not mathing where we would have hoped. Firstly, we have: {{{ Sequence (($WDone) `cast` ...) (...) }}} We would of course hope that the rule Sequence Done sa = sa would match here It's unclear if this is due to the `$WDone` or the `cast`. Certainly the conversion from Done to `$WDone` can be worked around by using a function {{{ {-# INLINE [0] done #-} done = Done }}} and changing the code and rules to use that. So the main problem is the one mentioned at the top of the ticket: {{{ failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that this rule would match {{{ Sequence (Sequence a b) c = Sequence a (Sequence b c) }}} So this is the same issue as in the artificial example but now additionally there's a `cast` in the way in the subterm. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 20:28:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 20:28:44 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.d349debc5c21fb4a2a13ba0996ee515f@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Oh wow, just looked at the test case you provided. It?s really small: {{{ 19 Form.hs 46 RegBig.hs 52 RegSmall.hs 17 Y.hs 134 insgesamt }} but indeed takes very long. We should certainly improve the situation here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 20:38:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 20:38:27 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.879f951ff6ef26b0b036f9ca3b70ac8a@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The source is very small, but the simplifier blows things up quite a lot, even though I have not used any INLINE directives. That is probably worth a separate issue. However, even after that blow-up the Core program size is not so unreasonably large that it should take several minutes to compile. (That is it is unreasonably large for the specific source program which produced it, but not unreasonably large for a different, reasonably large source program.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 20:41:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 20:41:28 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.0492f1df733b1dbf2393be69402e67bf@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Right. But the inliner issue needs to be recorded ? will you file a separate bug about this? Then we need a test case that exercises the elimCommonBlocks only. Let?s see if I can write some nonsensical code that is basically only a large number of almost equal blocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:10:06 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility Message-ID: <045.0008d7bf15a6c184529405e4260be834@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A module loaded by a plugin poisons the module cache, so we never load an orphan RULE or instance even if we legitimately should do so. The way to test this is a bit convoluted, but it goes something like this: plugins07.hs {{{ module Main where import Plugins07a import RuleDefiningPlugin {-# NOINLINE x #-} x = "foo" main = putStrLn (show x) }}} Plugins07a.hs {{{ --{-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} module Plugins07a where }}} RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't apply) {{{ module RuleDefiningPlugin where import GhcPlugins {-# RULES "unsound" forall x. show x = "SHOWED" #-} plugin :: Plugin plugin = defaultPlugin }}} I'll commit the full test. Here's what happens: * Building `Plugins07a` results in `loadPluginInterface` on `RuleDefiningPlugin`. We load the `ModIface` but only add its types to the environment because of the "Care with plugin imports" special case. * Building `plugins07.hs` results in a normal source level import for `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't load anything. RULE is not loaded, disaster! Admittedly, actually triggering this bug requires a convoluted chain of events. But really this problem arose because the "Care with plugin imports" fix is just completely nonsense. Here's what we should do: * We should apply the same fix from #2182 on orphan instances to orphan rules too. This way, we can safely load RULEs into the EPS without accidentally bringing them into scope when they shouldn't be. * Loading an interface should unconditionally suck in the instances and rules. The result is more correct and simpler, so it seems worth fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:10:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:10:55 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.bed578f4f3d8318b8687a1387cafb085@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > A module loaded by a plugin poisons the module cache, so we never load an > orphan RULE or instance even if we legitimately should do so. The way to > test this is a bit convoluted, but it goes something like this: > > plugins07.hs > {{{ > module Main where > > import Plugins07a > import RuleDefiningPlugin > > {-# NOINLINE x #-} > x = "foo" > > main = putStrLn (show x) > }}} > > Plugins07a.hs > {{{ > --{-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} > module Plugins07a where > }}} > > RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't > apply) > {{{ > module RuleDefiningPlugin where > > import GhcPlugins > > {-# RULES "unsound" forall x. show x = "SHOWED" #-} > > plugin :: Plugin > plugin = defaultPlugin > }}} > > I'll commit the full test. > > Here's what happens: > > * Building `Plugins07a` results in `loadPluginInterface` on > `RuleDefiningPlugin`. We load the `ModIface` but only add its types to > the environment because of the "Care with plugin imports" special case. > > * Building `plugins07.hs` results in a normal source level import for > `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't > load anything. RULE is not loaded, disaster! > > Admittedly, actually triggering this bug requires a convoluted chain of > events. But really this problem arose because the "Care with plugin > imports" fix is just completely nonsense. Here's what we should do: > > * We should apply the same fix from #2182 on orphan instances to orphan > rules too. This way, we can safely load RULEs into the EPS without > accidentally bringing them into scope when they shouldn't be. > > * Loading an interface should unconditionally suck in the instances and > rules. > > The result is more correct and simpler, so it seems worth fixing. New description: A module loaded by a plugin poisons the module cache, so we never load an orphan RULE or instance even if we legitimately should do so. The way to test this is a bit convoluted, but it goes something like this: plugins07.hs {{{ module Main where import Plugins07a import RuleDefiningPlugin {-# NOINLINE x #-} x = "foo" main = putStrLn (show x) }}} Plugins07a.hs {{{ {-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} module Plugins07a where }}} RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't apply) {{{ module RuleDefiningPlugin where import GhcPlugins {-# RULES "unsound" forall x. show x = "SHOWED" #-} plugin :: Plugin plugin = defaultPlugin }}} I'll commit the full test. Here's what happens: * Building `Plugins07a` results in `loadPluginInterface` on `RuleDefiningPlugin`. We load the `ModIface` but only add its types to the environment because of the "Care with plugin imports" special case. * Building `plugins07.hs` results in a normal source level import for `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't load anything. RULE is not loaded, disaster! Admittedly, actually triggering this bug requires a convoluted chain of events. But really this problem arose because the "Care with plugin imports" fix is just completely nonsense. Here's what we should do: * We should apply the same fix from #2182 on orphan instances to orphan rules too. This way, we can safely load RULEs into the EPS without accidentally bringing them into scope when they shouldn't be. * Loading an interface should unconditionally suck in the instances and rules. The result is more correct and simpler, so it seems worth fixing. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:12:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:12:05 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) Message-ID: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The test case for #10397 also demonstrates an exponential blowup by the inliner, without any INLINE pragmas. I added another four fields to the `Register` type, and I get these final Core program sizes. (The variation in sizes between versions is not really important, the point is just that they are very large for all versions.) {{{ ghc-7.6.3: *** CorePrep: Result size of CorePrep = {terms: 1,702,684, types: 1,950,647, coercions: 103} ghc-7.8.4: *** CorePrep: Result size of CorePrep = {terms: 1,964,183, types: 1,950,620, coercions: 97} ghc-7.10.1: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} ghc-7.11: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} }}} Ideally GHC should not produce enormous Core programs on its own like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:22:50 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.2ef038922318dba0d440b859e3873e05@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"ab45de12cee5af5dcb68b2afce1826ab9bf71ba0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ab45de12cee5af5dcb68b2afce1826ab9bf71ba0" Failing test for #10420 using plugins. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:23:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:23:33 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.558b45982acfea58cc9103d8a9911d62@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * testcase: => plugins07 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:25:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:25:38 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.bf1b6bc515e9667db72b3e64fd77d51b@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:5 nomeata]: > Right. But the inliner issue needs to be recorded ? will you file a separate bug about this? Done, #10421. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 22:56:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 22:56:17 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.60a9a4e4566b20ad823bf910a5392d16@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Despite the rule that one should set up a proper benchmark first, and then start hacking, I am now validating a patch that groups the blocks not only by hash, but also by the list of successor labels. These should be equal for all equal blocks, so we do not lose anything, but this should also give much smaller lists to search through linearly, and they can be updated with a new substitution without traversing the whole heap. I can probably report if that helps tomorrow. There are more way to improve the code (e.g. not repeatedly building this map, but rather working with one), but before I do that I really should get some benchmarks for this issue :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 15 23:36:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 May 2015 23:36:52 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.f66d22519887f150dbf8cdb0deafeed2@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I have Phab:D892, but I haven?t done any measurements yet, but for now it?s ?Good night?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 07:59:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 07:59:39 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.b19ffa22fc23196fa5d0ecd2f17fdc02@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): By adding `-debug` to `GhcStage2HcOpts` of `mk/build.mk` I turned up a different issue that I'm pretty sure is related, `inplace/bin/dll-split` exits with: {{{ dll-split: internal error: invalid closure, info=(nil) (GHC version 7.11.20150514 for aarch64_unknown_linux) }}} trigger by the assert: {{{ ASSERTM(LOOKS_LIKE_CLOSURE_PTR(q), "invalid closure, info=%p", q->header.info); }}} Adding a bit of `printf` debugging showed that the above assert passed a couple of hundred times before it found a NULL in `q->header.info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 09:31:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 09:31:59 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.4cd4617698f9d7a1926993b8dcf3cd37@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): The `ASSERTM` in the previous comment is in the file `rts/sm/Evac.c` in a funciton called `evacuate`. Adding a little more debugging and found that this `evacuate` function is called over 19000 times before the assertion is triggered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 11:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 11:03:05 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.8a98260e9b7a14b605e81330129d1f0f@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Compiling your `RegBig.hs`. Without `elimCommonBlocks`: > <> Before: > <> after my patch: > <> So it still takes long, but the time spend in `elimCommonBlocks` is cut down by ?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 11:23:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 11:23:01 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.ab1b8f9f25d4751610b64cb0fe2fde42@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): According to a profiled run, `elimCommonBlocks` now caters for 24.4% of the runtime, second to `sequenceBlocks` in `AsmCodeGen` with 59.5% (which I did not look at). `elimCommonBlocks` still spends most of the time comparing blocks, most of the time uselessly: It iterates, and in each iteration compares all blocks with the same hash key (hash + list of successor labels) again. This is pointless: If the list of successor labels has not changed, then the blocks cannot suddenly be equal. I have an idea how to avoid that. Let?s see if it pays off... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 14:21:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 14:21:54 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.30d257236ae2f64f5115071427b484c6@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Looks like it does: Down to 8.1% of the runtime! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 14:39:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 14:39:58 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.5077050a397ca9efbe8f794016f98154@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D892 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 15:52:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 15:52:56 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow Message-ID: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When working on #10397 and after fixing the bottleneck in `elimCommonBlocks` I noticed that `reorder` was taking most of the time. Bad lazy linked lists. I have a fix, will put it on Phabricator for validation shortly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 15:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 15:59:51 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.8429ade997c52bee26667673469d9c81@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): While working on this I found another bottleneck in the code generator, #10422. With that fixed? as well, we go from > <> to > <> Yay! ? patch pending validation, maybe I accidentially broke everything -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 16:04:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 16:04:33 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow In-Reply-To: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> References: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> Message-ID: <061.ae3a8afc830690db31f6b20c74f68281@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D893 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D893 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 16:34:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 16:34:41 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.a147d18344a17cfdc19e80e201b2ce73@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): And just to share the joy, here a side-by-side of the profile output, before and after: {{{ Sat May 16 18:12 2015 Time and Allocation Profiling Rep| Sat May 16 18:06 2015 Time and Allocation Profiling Rep | ghc-stage2 +RTS -t -p -RTS -B/home/jojo/build/haskel| ghc-stage2 +RTS -t -p -RTS -B/home/jojo/build/haskel | total time = 198.47 secs (198467 ticks @ 1000 u| total time = 14.22 secs (14225 ticks @ 1000 us total alloc = 97,018,068,880 bytes (excludes profiling| total alloc = 14,686,848,016 bytes (excludes profiling | COST CENTRE MODULE %time %alloc | COST CENTRE MODULE %time %alloc | elimCommonBlocks CmmPipeline 80.5 69.1 | elimCommonBlocks CmmPipeline 19.9 21.2 sequenceBlocks AsmCodeGen 13.6 19.2 | SimplTopBinds SimplCore 10.6 10.2 SimplTopBinds SimplCore 0.8 1.5 | pprNativeCode AsmCodeGen 7.6 8.5 pprNativeCode AsmCodeGen 0.7 1.3 | regLiveness AsmCodeGen 7.6 6.8 regLiveness AsmCodeGen 0.5 1.0 | StgCmm HscMain 5.6 5.3 RegAlloc AsmCodeGen 0.4 1.1 | RegAlloc AsmCodeGen 5.5 7.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 18:45:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 18:45:39 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.32aa19929a598f397417c527cff515f5@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by carter): can these patches apply cleanly to the 7.10 branch? if so i'd like to nominate them for 7.10.2! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 19:22:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 19:22:57 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.04df646bef580bc028b9410f486a2750@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): A quick `git rebase --onto origin/ghc-7.10 master` goes through fine (ignoring the test suite number update, which should probably be re-done anyways). But let?s first get them into master :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 19:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 19:54:58 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.039ab48f4064465e0a81e80d0faae4fc@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"c256357242ee2dd282fd0516260edccbb7617244/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c256357242ee2dd282fd0516260edccbb7617244" Speed up elimCommonBlocks by grouping blocks also by outgoing labels This is an attempt to improve the situation described in #10397, where the linear scan of possible candidates for commoning up is far too expensive. There is (ever) more room for improvement, but this is a start. Differential Revision: https://phabricator.haskell.org/D892 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 19:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 19:54:58 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.f7b3b4a6596e408eed6f0dfb18082cc6@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d" Greatly speed up nativeCodeGen/seqBlocks When working on #10397, I noticed that "reorder" in nativeCodeGen/seqBlocks took more than 60% of the time. With this refactoring, it does not even show up in the profile any more. This fixes #10422. Differential Revision: https://phabricator.haskell.org/D893 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 19:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 19:54:58 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow In-Reply-To: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> References: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> Message-ID: <061.6aa871a52907aa8bd71af7a0e16a1de4@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D893 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d" Greatly speed up nativeCodeGen/seqBlocks When working on #10397, I noticed that "reorder" in nativeCodeGen/seqBlocks took more than 60% of the time. With this refactoring, it does not even show up in the profile any more. This fixes #10422. Differential Revision: https://phabricator.haskell.org/D893 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 19:55:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 19:55:54 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow In-Reply-To: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> References: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> Message-ID: <061.1802fa22c0cec08b99549a2c5bdcc1d8@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D893 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: carter suggested that this might be 7.10 material. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 20:32:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 20:32:01 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.b937eaf53422b72196fd06d7ebc3ea4b@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 21:19:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 21:19:30 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.0d1a00c2cf4b7c994affa2aea1ecf6e6@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Changes (by carter): * milestone: => 7.10.2 Comment: setting a milestone so its on the table for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 21:21:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 21:21:20 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow In-Reply-To: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> References: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> Message-ID: <061.d403bcb6735487980cedd9361867010d@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D893 -------------------------------------+------------------------------------- Changes (by carter): * milestone: => 7.10.2 Comment: this should be on the table for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 16 21:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 May 2015 21:21:40 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.53ad62519b37501faa9fa45b426f773a@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by carter): setting a milestone so its on the table for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 01:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 01:57:49 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.4c21c790d854ed6e9112cf4724c18f49@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hsyl20): I have an additional fix to propose for this bug: handle Unicode to ASCII conversions in GHC without Iconv: {{{ diff --git a/libraries/base/GHC/IO/Encoding.hs b/libraries/base/GHC/IO/Encoding.hs index 31683b4..c67f317 100644 --- a/libraries/base/GHC/IO/Encoding.hs +++ b/libraries/base/GHC/IO/Encoding.hs @@ -243,6 +243,7 @@ mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of "UTF32" -> return $ UTF32.mkUTF32 cfm "UTF32LE" -> return $ UTF32.mkUTF32le cfm "UTF32BE" -> return $ UTF32.mkUTF32be cfm + "ANSI_X3.41968" -> return char8 -- match "ANSI_X3.4-1968" (ASCII) #if defined(mingw32_HOST_OS) 'C':'P':n | [(cp,"")] <- reads n -> return $ CodePage.mkCodePageEncoding cfm cp _ -> unknownEncodingErr (enc ++ codingFailureModeSuffix cfm) }}} It seems that static binaries fall back to ASCII even if the current locale is UTF-8. ASCII is identified with the string "ANSI_X3.4-1968" on my system (Linux 4.0, glibc 2.21). Maybe we should match other possible aliases? I tested this patch with a single static binary in a initramfs and it works fine now. It should fix #7695 too (single static binary in a chrooted environment). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 02:24:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 02:24:22 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.b3da4ec39ceb2f46b1549e62a408cbb6@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hsyl20): Fixed with my patch for #10298 (see my comment there). Can you check that you obtain the same result on your system with this code: {{{ $> cat test.c #include #include #include int main() { setlocale(LC_CTYPE, ""); printf("LC_CTYPE: %s\n", nl_langinfo(CODESET)); return 0; } $> gcc -static -L/path/to/static/glibc test.c -o test $> sudo chroot `pwd` /test LC_CTYPE: ANSI_X3.4-1968 }}} I don't know if the default LC_CTYPE is the same everywhere... (You should get the same result if you have compiled the glibc with --disable-shared when you call ./test directly without the chroot) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 05:36:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 05:36:21 -0000 Subject: [GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT In-Reply-To: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> References: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> Message-ID: <060.99a619f199da907bb842006e561dd9f6@haskell.org> #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: My original motivation was clarity surrounding plugin interface loading, but actually I think there's a better way to solve this problem (#10420), so I guess let's let this die. Though, I think it may still be useful to add a new function to `LoadIface` expressly for orphan loading, to consolidate this logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 07:57:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 07:57:14 -0000 Subject: [GHC] #10423: Can't infer Monad n from (Monad m, m ~ n) Message-ID: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> #10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This looks like a regression in GHC HEAD. {{{ Test/SmallCheck/Property.hs:187:10: Could not deduce (Monad n) arising from the superclasses of an instance declaration from the context: (Monad m, m ~ n) bound by the instance declaration at Test/SmallCheck/Property.hs:187:10-52 Possible fix: add (Monad n) to the context of the instance declaration In the instance declaration for ?Testable n (Property m)? }}} The code is here: https://github.com/feuerbach/smallcheck/blob/v1.1.1/Test/SmallCheck/Property.hs#L187-L188 Originally reported here: https://github.com/feuerbach/smallcheck/issues/28 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 08:19:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 08:19:18 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant In-Reply-To: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> References: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> Message-ID: <063.f0b9ac09420db9918e10cb41032d0c29@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Feuerbach): How about including all local bindings that are in scope at that point? The motivation is: 1. Some of the local bindings will likely be used to fill in the hole 2. There are typically not too many of them, so the output will stay relevant (as opposed to including global bindings, too) 3. The feature is especially useful for local bindings, since getting their type requires a bit of extra work (again, as opposed to global bindings) I don't have an opinion on whether this should replace or be added to the current type-based algorithm which you describe (and which I wasn't aware of until now). Although if I understand the current algorithm correctly, it will only ever report bindings from the current declaration (since type variables cannot be shared across declarations), so in that case my proposal seems to be about simply lifting the type-based restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 12:46:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 12:46:26 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.41bc02290ab1d566942f56d8fba8a020@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D894 Related Tickets: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => patch * differential: => Phab:D894 Comment: Created DR with a more detailed comment https://phabricator.haskell.org/D894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 17:23:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 17:23:26 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.778870fd532b9cd46db008dddd494f46@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * status: closed => new * resolution: fixed => Comment: Can the testcase in Simon's `Test Trac #10403` commit be changed to how it should be? `h :: _ => _` doesn't trigger the bug, only `h :: _` does (and I don't know why Simon changed it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 18:07:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 18:07:16 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes Message-ID: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The build path of GHC leaks into the ABI hashes, i.e. if you build GHC in /tmp/fooADDF and then in /tmp/fooSDFS, you get different ABI hashes. This is a serious problem for distributions, as it means that we cannot rebuild the GHC package without rebuilding all Haskell packages as well. The (or at least one) problem is include paths. We have {{{ include-dirs: /home/jojo/build/haskell/ghc/rts/dist/build /home/jojo/build/haskell/ghc/includes /home/jojo/build/haskell/ghc/includes/dist- derivedconstants/header }}} in `inplace/lib/package.conf.d/builtin_rts.conf`, so when running the preprocessor, GHC passes this full path to the preprocessor: {{{ /usr/bin/gcc -E -undef -traditional -DOPTIMISE_INTEGER_GCD_LCM -include libraries/base/dist-install/build/autogen/cabal_macros.h -I libraries/base /dist-install/build -I libraries/base/dist-install/build -I libraries/base /dist-install/build/autogen -I libraries/base/include -I /home/jojo/build/haskell/ghc/libraries/integer-gmp/include -I /home/jojo/build/haskell/ghc/rts/dist/build -I /home/jojo/build/haskell/ghc/includes -I /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=711' -include /home/jojo/build/haskell/ghc/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' '-D__SSE__=1' '-D__SSE2__=1' -x assembler- with-cpp libraries/base/System/Info.hs -o /tmp/ghc14804_0/ghc14804_1.hscpp }}} It then reads the included files from the `hscpp` file : {{{ $ grep home /tmp/ghc14830_0/ghc14830_1.hscpp # 1 "/home/jojo/build/haskell/ghc/includes/ghcversion.h" 1 # 1 "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" 1 }}} and puts it into the interface, where it becomes part of the hash: {{{ $ ./inplace/bin/ghc-stage1 --show-iface ./libraries/base/dist- install/build/System/Info.hi |grep Dep addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcversion.h" addDependentFile "libraries/base/dist- install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" }}} Clearly, the end result is undesirable (changing hashes due to path names) and actually useless, as the build path will not be there later anyways. I?m not sure what the best way to fix this is. Here are a few ideas: * Do not include the path of `addDependentFile` entries in the hash, but only the file hash. Should solve the ABI hash. * Use relative paths in `inplace/lib/package.conf.d/builtin_rts.conf`. Not sure what breaks. This bug appeared in 7.8.4 and is present in both 7.10 and current HEAD. Any other ideas? (Debian bugreport at http://bugs.debian.org/785282) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 18:08:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 18:08:15 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.2dff9eb6a579d35eb5bb5c32e4f59e48@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #4012 Comment: #4012 is related, but not fully: I guess #4012 would be fixed if compilation is deterministic in the same environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 20:58:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 20:58:39 -0000 Subject: [GHC] #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 Message-ID: <042.88dde6c88a2451f4e68effb85ca57c32@haskell.org> #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the '''pdf''' version of User's Guide Version 7.10.1, the first example of "Section 13.1.1.2 Contex-free syntax" has the following wrong indentation: {{{#!hs main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps }}} The HTML version is OK, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 21:13:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 21:13:32 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.c193a0cddf52cd2db5d6e8b065cc6fac@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Here is a possible fix: {{{ diff --git a/compiler/iface/MkIface.hs b/compiler/iface/MkIface.hs index 9a2cd35..180742f 100644 --- a/compiler/iface/MkIface.hs +++ b/compiler/iface/MkIface.hs @@ -622,7 +622,7 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls iface_hash <- computeFingerprint putNameLiterally (mod_hash, ann_fn (mkVarOcc "module"), -- See mkIfaceAnnCache - mi_usages iface0, + usages, sorted_deps, mi_hpc iface0) @@ -655,6 +655,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0) fix_fn = mi_fix_fn iface0 ann_fn = mkIfaceAnnCache (mi_anns iface0) + -- Do not allow filenames to affect the interface + usages = [ case u of UsageFile _ fp -> UsageFile "" fp; _ -> u | u <- mi_usages iface0 ] + getOrphanHashes :: HscEnv -> [Module] -> IO [Fingerprint] getOrphanHashes hsc_env mods = do }}} This excludes the actual filename from the hash generation. It seems to solve the problem for Debian (so likely we will use it). But I also think it is generally fine to have. It would be bad if the hash would not change although we should recompile depending modules. But even if the actual filenames change for some reason, as long as their content was the same (and the file?s hash is part of the module hash), I don?t think we have to recompile the depending modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 17 21:29:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 May 2015 21:29:04 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms Message-ID: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> #10426: matchGroupArity panic with PatternSynonyms ---------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, EmptyCase #-} pattern Id <- (id -> _) where }}} which gives: {{{#!hs % ghc -ignore-dot-ghci tmp.FbbzjZ48OO.hs [1 of 1] Compiling Main ( tmp.FbbzjZ48OO.hs, tmp.FbbzjZ48OO.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): matchGroupArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 00:21:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 00:21:49 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.87ddef4aaf9c287f0d1dcd3996a3e64e@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * version: 7.11 => 7.10.1 * milestone: 7.12.1 => 7.10.2 Comment: Problem also exists on the `ghc-7.10` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 00:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 00:34:24 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.79170efb6f8ca9fb353417727cbebc81@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): If I compile the RTS with `-debug` and run {{{ inplace/bin/ghc-stage +RTS -DS -Dl -RTS --interactive }}} it fails as follows: {{{ Prelude> data X = A | B deriving Eq lookupSymbol: looking up ghczmprim_GHCziTypes_True_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziTypes_False_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziTypes_False_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziTypes_True_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziClasses_DZCEq_con_info lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziClasses_zeze_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziClasses_not_closure lookupSymbol: symbol not found Prelude> A == A lookupSymbol: looking up ghczmprim_GHCziClasses_zeze_closure lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziTypes_ZC_con_info lookupSymbol: symbol not found lookupSymbol: looking up ghczmprim_GHCziTypes_ZMZN_closure lookupSymbol: symbol not found lookupSymbol: looking up base_GHCziBase_returnIO_closure lookupSymbol: symbol not found lookupSymbol: looking up base_GHCziShow_zdfShowBool_closure lookupSymbol: symbol not found lookupSymbol: looking up base_SystemziIO_print_closure lookupSymbol: symbol not found lookupSymbol: looking up base_GHCziBase_thenIO_closure lookupSymbol: symbol not found Segmentation fault }}} This (apart from the segfault) is identical to what happens on x86_64/linux compiled the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 00:48:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 00:48:52 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.378070afca8950f1d43148885fb2deaf@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by rwbarton): That means the beginning of a closure (heap object) got overwritten with zeros somehow and it was discovered during garbage collection. Have you tried running with `-DS`? That might find the offender earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 00:52:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 00:52:02 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.0e764f0f6db6836be8b85b890ca8ef76@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Turning the test case into a script: {{{ data X = A | B deriving Eq A == A }}} and running as: {{{ inplace/bin/ghc-stage2 +RTS -Ds -Di -RTS --interactive < ghci- segfault.script }}} results in: {{{ evaluating unknown closure -- yielding to sched Object 0xb06446a4 = BLACKHOLE(0xb0619a6c) b14ff460: cap 0: thread 17 stopped (yielding) b14ff460: --<< thread 17 (ThreadRunGHC) stopped to switch evaluators b14ff460: cap 0: running thread 17 (ThreadRunGHC) Segmentation fault }}} The `x86_64/linux` version also has this stuff but doesn't segfault: {{{ evaluating unknown closure -- yielding to sched Object 0x7fbea1548150 = BLACKHOLE(0x7fbea1858cb8) 7fbea22fd700: cap 0: thread 19 stopped (yielding) 7fbea22fd700: --<< thread 19 (ThreadRunGHC) stopped to switch evaluators 7fbea22fd700: cap 0: running thread 19 (ThreadRunGHC) 7fbea22fd700: cap 0: thread 19 stopped (yielding) 7fbea22fd700: --<< thread 19 (ThreadInterpret) stopped to switch evaluators 7fbea22fd700: cap 0: running thread 19 (ThreadInterpret) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 01:38:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 01:38:59 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.655172cbca593050baee9590eebe190e@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I tried to investigate this, but Agda has a bunch of upper bounds that rule out building with 7.10, and with `--allow-newer`, I got an error about `No instance for (GHC.Generics.Generic (Ptr a))` and gave up. How did you manage to build Agda with 7.10 in the first place? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 01:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 01:49:03 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.6535aadc99d8aafe2b743b5007a64aba@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, the unreleased version on github seems to be building with 7.10. Maybe GHC failing to build Agda on machines with low memory is a feature, since Agda itself needs so much memory to typecheck anything anyways :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 02:28:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 02:28:27 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.77e80f8bf757b7e9cc28f40fc6849e97@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): This came into my head again, and can be simplified, and I think clarified, like so: {{{#!hs import Control.Parallel.Strategies import System.Environment parConcatMapN :: Int -> Int -> (a -> [a]) -> a -> [a] parConcatMapN chunksize depth step = go depth where go 0 = (:[]) go n = withStrategy (parListChunk chunksize rseq) . concatMap (go (n-1)) . step main :: IO () main = do depth:_ <- fmap (map read) getArgs print $ length (test depth) test depth = parConcatMapN 3 depth show 'x' -- i.e. iterate (concatMap show) 'x' !! depth }}} We keep re-chunking, but do not respect the chunking we already did, in the would-be progress through {{{ 'x' '\'''x''\'' '\'''\\''\'''\'''\'''x''\'''\'''\\''\'''\'' ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 02:36:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 02:36:36 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.2c23d16a3998881c93d9f677b65f3502@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): A bit of `printf` debugging shows that the segault is happening in the `schedule` function of `rts/Schedule.c`, specifically on the call to `StgRun` around line number 460: {{{ case ThreadRunGHC: { StgRegTable *r; r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r); cap = regTableToCapability(r); ret = r->rRet; break; } }}} and on Arm, I have confirmed that `StgRun` is the assembler version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 03:24:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 03:24:05 -0000 Subject: [GHC] #10427: Template variable unbound in rewrite rule Message-ID: <047.f4beb6a1fbda45d3d0b7dd0171e3ec9f@haskell.org> #10427: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This may be due to a bug in [singletons](https://hackage.haskell.org/package/singletons), but GHC requested I post a bug here, so I am dutifully complying. The following code fails with -O2 (but succeeds with -O1): {{{#!hs {-# LANGUAGE DataKinds, GADTs, KindSignatures, PolyKinds, ScopedTypeVariables, TemplateHaskell, TypeFamilies, UndecidableInstances #-} module Error where import qualified GHC.Num as Num import Data.Singletons.Prelude hiding (sMin, sMax, MinSym0, MaxSym0) import Data.Singletons.TH import Data.Type.Natural as N hiding ((:-)) singletons [d| newtype Foo = Bar Nat deriving (Eq,Show) |] singletons [d| ppMul :: Foo -> [Foo] -> [Foo] ppMul x@(Bar p) pps@((Bar p'):pps') = (Bar p'):ppMul x pps' |] }}} with the message {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Template variable unbound in rewrite rule n_Xdkc [n_adis, n1_adix, n_adiA, sc_se5w, sg_se5x, sc_se5y] [n_Xdk2, n1_Xdk8, n_Xdkc, sc_Xe79, sg_Xe7b, sc_Xe7d] [TYPE Let_1627437169XSym3 n_adis n_adiA n1_adix, TYPE n1_adix, (SBar @ ('Bar n_adis) @ n_adis @~ <'Bar n_adis>_N sc_se5w) `cast` (sg_se5x :: R:SingFooz (BarSym1 n_adis) ~R# Sing (Apply BarSym0 n_adis)), sc_se5y] [TYPE Let_1627437169XSym3 n_adis n_XdjP n1_XdjH, TYPE n1_XdjH, (SBar @ ('Bar n_adis) @ n_adis @~ <'Bar n_adis>_N sc_se5w) `cast` (Sub (Sym TFCo:R:SingFooz[0]) (Sym (TFCo:R:ApplyFooNatBarSym0l0[0] _N)) :: R:SingFooz (BarSym1 n_adis) ~R# Sing (Apply BarSym0 n_adis)), sPps'_aciK] }}} I found that if I rewrite `ppmul` as `ppMul x pps@((Bar p'):pps') = (Bar p'):ppMul x pps'` (i.e. remove the pattern match on `x`), then ghc -02 succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 03:28:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 03:28:27 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint Message-ID: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles in 7.8.4 but fails in 7.10.1: {{{#!hs import Data.Coerce coerceNewtype :: (Coercible (o r) (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} with the error {{{ Couldn't match representation of type ?n m' r? with that of ?o r? arising from trying to show that the representations of ?[o r]? and ?[n m' r]? are the same Relevant role signatures: type role [] representational }}} However, the following compiles: {{{#!hs {-# LANGUAGE TypeFamilies #-} import Data.Coerce coerceNewtype :: (Coercible a b, a ~ (o r), b ~ (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 03:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 03:43:21 -0000 Subject: [GHC] #10427: Template variable unbound in rewrite rule In-Reply-To: <047.f4beb6a1fbda45d3d0b7dd0171e3ec9f@haskell.org> References: <047.f4beb6a1fbda45d3d0b7dd0171e3ec9f@haskell.org> Message-ID: <062.a57ba281cedfb03663b3d9ee3e8780e5@haskell.org> #10427: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Appears to be a duplicate of #10251, which appears to be fixed for 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 03:46:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 03:46:40 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.716c8246ccbe2628b91a71580427f41d@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Hmpf. I'm not terribly surprised that this would happen, but we should be able to nab such an easy case. Will take a look. But not this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 03:48:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 03:48:08 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.20ac6d61091c629192ced02b63712f54@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): What I'd like to do at this point is to run `ghc-stage` under GNU GDB. To load it in GDB, I've copied `inplace/bin/ghc-stage2` and added `gdb --args` in front of the line: {{{ "$executablename" -B"$topdir" ${1+"$@"} }}} I've also created a `.ghci` file in the current directory containing the test case from #comment:8 and tested that it behaves correctly with GDB. Unfortunately, with GDB, the problem is not triggered, I suspect because of some interaction between GDB and GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 04:23:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 04:23:14 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.87554c3910a1472a91a175ad626cb4e8@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The memory usage is up only 10% over 7.8, so this doesn't seem to be a significant regression. {{{ 7.8 327,943,402,392 bytes allocated in the heap 18,580,963,960 bytes copied during GC 870,373,552 bytes maximum residency (24 sample(s)) 13,857,232 bytes maximum slop 2446 MB total memory in use (0 MB lost due to fragmentation) 7.10 506,171,221,880 bytes allocated in the heap 34,277,256,496 bytes copied during GC 945,447,464 bytes maximum residency (35 sample(s)) 18,326,864 bytes maximum slop 2681 MB total memory in use (0 MB lost due to fragmentation) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 04:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 04:29:44 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.f627b07e574f17f321fdb40fe006ea20@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Managed to run `ghc-stage2 --interactive` in one terminal and the attach GDB to it in another using `ghc -tui -p `. I can then manually enter the two lines of test case code and have it segfault. The GDB backtrace is a little odd (even by haskell program standards): {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb14ff460 (LWP 19914)] Cannot access memory at address 0xb88849d4 (gdb) bt #0 0xb88849d4 in ?? () #1 0x70000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} but that address `0xb88849d4` being in both the "Cannot access memory at" message and the stack might point to stack corruption while the `0x70000000` address on the stack is *very* suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 05:56:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 05:56:48 -0000 Subject: [GHC] #10429: GHC fails to import instance Message-ID: <047.e8811068988b7083104822369fae40ba@haskell.org> #10429: GHC fails to import instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles in 7.8.4 but fails to compile in 7.10.1. Tagged.hs {{{#!hs module Tagged where import Control.Monad.Trans newtype TaggedT s m b = TagT (m b) instance MonadTrans (TaggedT s) }}} Main.hs {{{#!hs import Control.Monad.Trans.Class import Tagged returnT :: (MonadTrans t) => t m a -> t m a returnT a = undefined f :: TaggedT Int m a -> TaggedT Int m a f = returnT }}} GHC complains {{{ Could not deduce (MonadTrans (TaggedT Int)) arising from a use of ?returnT? }}} If I change the import in Main to `Control.Monad.Trans`, 7.10.1 accepts the program. Since the import `Control.Monad.Trans` is actually a folder, the class `MonadTrans` must refer to the definition in `Control.Monad.Trans.Class`, so GHC should find the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 07:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 07:38:58 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.0a4b3a799a328fe2385c37ee0c779815@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by simonpj): That's a trememdous improvement, thanks Joachim. That said, 20% of compilation time in one, relatively minor, optimisation is far too much. I wonder how we could improve matters further? For example, the bigger the block the less likely it is to be identical, but the more expensive it is to compare (I guess). Maybe we can cut off at some block size? Also why are you comparing (hash, list of successor labels) rather than just including the successor labels in the hash? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 07:49:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 07:49:27 -0000 Subject: [GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT In-Reply-To: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> References: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> Message-ID: <060.a95f0a36584f7dc6595e16aa3129a934@haskell.org> #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > Though, I think it may still be useful to add a new function to `LoadIface` expressly for orphan loading, to consolidate this logic. Maybe so. Which logic did you have in mind, and where is it duplicated? Can you suggest a patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 07:52:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 07:52:12 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant In-Reply-To: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> References: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> Message-ID: <063.1ad2d4e769492e7f558bfc5c7d999c76@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > How about including all local bindings that are in scope at that point? I wouldn't be against that. I assume it would ''replace'' the current algorithm, at least for holes. (After all, it'll report a superset of the former algorithm.) What do others think? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 07:52:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 07:52:12 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.d7bad5c4f183475918f4f3f59d534373@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): Note that this is a rather extreme test case. I?m sure for a lot of optimizations we can construct a case where they account for most of the program. If it were 20% for a real-world example, I?d fully agree. Right now, I?m fine with the current state of affairs. > For example, the bigger the block the less likely it is to be identical, but the more expensive it is to compare (I guess). Maybe we can cut off at some block size? I doubt it. The bigger the blocks, the more likely it is that the hash is different. > Also why are you comparing (hash, list of successor labels) rather than just including the successor labels in the hash? Because the successor labels change (or rather the equality on them) as we common up blocks; the hash is calculated exactly once. I guess you are implicitly asking for more comments. Added it to the body of text already there. I wonder if it is faster to hash the list of labels and group them using a single level IntMap instead of the current trie based on nested IntMap.... That?s worth a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:08:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:08:40 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.125f15c4cdc15a59cfdb9d9012ac1cb6@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:23 nomeata]: > I wonder if it is faster to hash the list of labels and group them using a single level IntMap instead of the current trie based on nested IntMap.... That?s worth a try. no, it?s not. And profiling shows why: The time is still spent mostly in `eqBlockBodyWith`. With my refactoring, the number of calls to that function is minimal anyways, so the only way to improve the situation is * a better hash function (it currently does not take operators into account, and maybe it can also take ?internal? functions into account) * no linear search by using a trie for blocks, similar how we do it for Core expressions. * lose precision. I?ll add some debug output to see how these blocks that cannot be merged look like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:10:43 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.165815339b2f7246825aec1e6e36a476@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Yes, tied `+RTS -DS -RTS` and the only extra debug output I get is: {{{ cap 0: initialised }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:11:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:11:19 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.3688b0c5473ea5bd276d131f4168cff2@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Looks sensible to me, although I am not deep into ABI hashes. '''Is there a single Note where the desired semantics of ABI hashes are explained?''' Including the consequences for distros, which led to this ticket being created? Then we could refer to that Note from here. The comment "Do not allow filenames to affect the interface" just isn't enough! Even an inadequate Note would be better than none. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:32:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:32:03 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.21fc97e20ad3d41f447fb18407958b93@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791, Phab:D895 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: Phab:D731, Phab:D791 => Phab:D731, Phab:D791, Phab:D895 Comment: Added regression test in Phab:D895 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:32:23 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.63d8a7694d40193b87f035c01e8ba4fc@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791, Phab:D895 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:33:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:33:57 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.3e7de1fbba237273b28b52eca6bcbd07@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by alanz: Old description: > A collection of minor updates for the API Annotations. > > 1. The annotations for the implicity parameter is disconnected in the > following > > {{{#!hs > type MPI = ?mpi_secret :: MPISecret > }}} > > 2. In the following, the annotation for one of the commas is > disconeected. > > {{{#!hs > mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form) > }}} > > 3. In the following, the annotation for the parens becomes disconnected > > {{{#!hs > data MaybeDefault v where > SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v > }}} New description: A collection of minor updates for the API Annotations. 1. The annotations for the implicity parameter is disconnected in the following {{{#!hs type MPI = ?mpi_secret :: MPISecret }}} 2. In the following, the annotation for one of the commas is disconeected. {{{#!hs mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form) }}} 3. In the following, the annotation for the parens becomes disconnected {{{#!hs data MaybeDefault v where SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:37:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:37:08 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.68f676850fb33d66ace7652b5da12240@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Tried a bunch of other `-Dx` RTS debugging options as found in https://ghc.haskell.org/trac/ghc/wiki/Debugging/RuntimeSystem but none of them provide any new information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:38:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:38:47 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.5b67747d2efc2173658b47d0bf29fba8@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 -------------------------------------+------------------------------------- Comment (by nomeata): Geez, how do I print these `CmmBlocks`? The lack of ubiquitous `Outputable` or `Show` instances can be quite a time waster.... ah `import PprCmm ()` helps. Indeed, the hash function is simply not fine-grained enough. Including the uniques of local registers yields {{{ ghc-stage2 +RTS -t -p -RTS -B/home/jojo/build/haskell/ghc| ghc-stage2 +RTS -t -p -RTS -B/home/jojo/build/haskell/gh | total time = 13.83 secs (13831 ticks @ 1000 us, 1 p| total time = 11.79 secs (11791 ticks @ 1000 us, 1 total alloc = 14,684,289,032 bytes (excludes profiling over| total alloc = 11,894,920,976 bytes (excludes profiling ove | COST CENTRE MODULE %time %alloc | COST CENTRE MODULE %time %alloc | elimCommonBlocks CmmPipeline 17.4 21.2 | SimplTopBinds SimplCore 12.7 12.6 SimplTopBinds SimplCore 11.1 10.2 | regLiveness AsmCodeGen 9.4 8.4 regLiveness AsmCodeGen 7.7 6.8 | pprNativeCode AsmCodeGen 8.3 10.5 pprNativeCode AsmCodeGen 7.0 8.5 | RegAlloc AsmCodeGen 7.1 8.8 RegAlloc AsmCodeGen 5.9 7.1 | StgCmm HscMain 6.9 6.5 StgCmm HscMain 5.6 5.3 | sink CmmPipeline 6.3 5.9 sink CmmPipeline 5.3 4.7 | genMachCode AsmCodeGen 3.9 3.7 genMachCode AsmCodeGen 3.5 3.0 | layoutStack CmmPipeline 3.9 4.0 layoutStack CmmPipeline 3.5 3.2 | do_block Hoopl.Dataflow 3.2 1.9 do_block Hoopl.Dataflow 2.7 1.5 | postorderDfs CmmUtils 2.9 2.4 NativeCodeGen CodeOutput 2.4 2.2 | NativeCodeGen CodeOutput 2.7 2.7 postorderDfs CmmUtils 2.3 2.0 | elimCommonBlocks CmmPipeline 2.5 2.8 sequenceBlocks AsmCodeGen 2.0 1.8 | sequenceBlocks }}} which now should be finally sufficient. Will create a DR for validation and then push this. I also replaced my fancy trie by a plain `Data.Map`. It turned out to be not performance critical, so let?s remove the custom code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:51:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:51:04 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.de5d0eba97c3083d1112e1b1c04a1b19@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Changes (by nomeata): * differential: Phab:D892 => Phab:D892 Phab:D896 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:54:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:54:20 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.fc26626d488fce10d15ecd53bfca96e7@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Comment (by simonpj): Yay, great stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 08:57:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 08:57:04 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.80045b1ef852d8e706e9aa1f8f229a4d@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Curious. With HEAD I get {{{ T10428.hs:5:18: error: Couldn't match representation of type ?o r? with that of ?n m' r? Inaccessible code in the type signature for: coerceNewtype :: Coercible (o r) (n m' r) => [o r] -> [n m' r] In the ambiguity check for the type signature for ?coerceNewtype?: coerceNewtype :: forall (o :: * -> *) r (n :: * -> * -> *) m'. Coercible (o r) (n m' r) => [o r] -> [n m' r] To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?coerceNewtype?: coerceNewtype :: (Coercible (o r) (n m' r)) => [o r] -> [n m' r] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 10:07:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 10:07:57 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure Message-ID: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In System/IO.hs I see two typos: {{{#!hs openTempFileWithDefaultPermissions :: FilePath -> String -> IO (FilePath, Handle) openTempFileWithDefaultPermissions tmp_dir template = openTempFile' "openBinaryTempFile" tmp_dir template False 0o666 }}} It should read {{{openTempFile' "openTempFileWithDefaultPermssions"}}}. The function {{{openBinaryTempFileWithDefaultPermissions}}} has the same bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 10:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 10:08:22 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure In-Reply-To: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> References: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> Message-ID: <066.8247a6882b74ba71e08c0a2aacff64c3@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 10:53:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 10:53:06 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.9d018e738a8eb1ca04b474deeaada6ca@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by bgamari): Hmm, excellent sleuthing work so far. Have you tried running in Valgrind? It typically struggles to do anything useful on Haskell code but you never know. You may also want to add a `printf` outputting all of the relevant local bindings around line 460 to see where exactly this mysterious address is coming from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 11:12:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 11:12:11 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.d3ab58000e1e233e8d39b479df18d30d@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"73f836f5d57a3106029b573c42f83d2039d21d89/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="73f836f5d57a3106029b573c42f83d2039d21d89" CmmCommonBlockElim: Improve hash function Previously, the hash function used to cut down the number of block comparisons did not take local registers into account, causing far too many similar, but different bocks to be considered candidates for the (expensive!) comparision. Adding register to the hash takes CmmCommonBlockElim's share of the runtime of the example in #10397 from 17% to 2.5%, and eliminates all unwanted hash collisions. This patch also replaces the fancy trie by a plain Data.Map. It turned out to be not performance critical, so this simplifies the code. Differential Revision: https://phabricator.haskell.org/D896 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 12:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 12:45:17 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.85e383d84ed0beab922901f5a29b03a6@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | perf/should_run/T10359 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3f42de51ab2de697089917ee71feec9a7333dd0d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3f42de51ab2de697089917ee71feec9a7333dd0d" Test Trac #10359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 12:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 12:45:17 -0000 Subject: [GHC] #10403: GHC crashes on a partial type signature In-Reply-To: <051.3964e20a20585ae510669b50854eeffc@haskell.org> References: <051.3964e20a20585ae510669b50854eeffc@haskell.org> Message-ID: <066.7a4be43334f699cde00dc00f5502f800@haskell.org> #10403: GHC crashes on a partial type signature -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f1f265df0742b7214f3b909190f5a171819392b5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f1f265df0742b7214f3b909190f5a171819392b5" Test Trac #10403 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 12:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 12:45:18 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.aaeb34494e20efd30de4f04a752ff8bc@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fa0bdd3d6e1fa7bca044ee13b84f6aeeacbe50e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa0bdd3d6e1fa7bca044ee13b84f6aeeacbe50e2" Test Trac #10248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 12:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 12:45:18 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.dd47157661b3b2045e2d27f20fb36066@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | perf/should_run/T10359 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ffc21506894c7887d3620423aaf86bc6113a1071/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ffc21506894c7887d3620423aaf86bc6113a1071" Refactor tuple constraints Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity - Haddock needs to absorb the change too; so there is a submodule update }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 12:45:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 12:45:18 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.0f6c33a59d6be7dfc0e01816680b61ed@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ffc21506894c7887d3620423aaf86bc6113a1071/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ffc21506894c7887d3620423aaf86bc6113a1071" Refactor tuple constraints Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity - Haddock needs to absorb the change too; so there is a submodule update }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:02:49 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.967aba6105efec12d2a90663b7ad196f@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): comment:2 really shouldn't happen. That one surprises me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:18:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:18:22 -0000 Subject: [GHC] #10429: GHC fails to import instance In-Reply-To: <047.e8811068988b7083104822369fae40ba@haskell.org> References: <047.e8811068988b7083104822369fae40ba@haskell.org> Message-ID: <062.bfea0dfd99a9f20aa64070676f0729b9@haskell.org> #10429: GHC fails to import instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: You have two versions of `transformers` installed under 7.10. See http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions or search Google for "No instance for MonadTrans" for more information. Also see #9611 about improving the error message in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:38:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:38:28 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.58a95314ad500665b497fb3bb2510fa4@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:38:41 -0000 Subject: [GHC] #10422: reorder in nativeCodeGen too slow In-Reply-To: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> References: <046.6c76e4ed285c46858b75a2d1dece93d8@haskell.org> Message-ID: <061.766a879ff9692273b1112da4ec53e725@haskell.org> #10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D893 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:38:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:38:47 -0000 Subject: [GHC] #10335: Failure to construct superclasses in instance In-Reply-To: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> References: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> Message-ID: <061.404e1abb71776f144bd4af2880c505df@haskell.org> #10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10335 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 13:40:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 13:40:26 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.663d80cf6682a160aa2d085e82f0d0d5@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge Comment: I guess 73f836f5d57a3106029b573c42f83d2039d21d89, a further improvement over the previous patch, should also go into 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 14:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 14:41:46 -0000 Subject: [GHC] #10431: EqualityConstraints extension? Message-ID: <049.f083101907b8bce0e20c55864639c7df@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, writing an equality constraint in a type requires at least one of the `GADTs` or `TypeFamilies` extensions. However, each of these has other effects. Could we have an `EqualityConstraints` extension to permit equality constraints in types, but neither GADTs nor type families? Presumably this extension should imply `MonoLocalBinds`. The `GADTs` extension could then become precisely the conjunction of `GADTSyntax`, `EqualityConstraints` and `ExistentialQuantification`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 17:40:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 17:40:20 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.b7b95c3306c0242c88d3e101f5c1bafc@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Comment (by TobyGoodwin): Fantastic work on this. Can I just point out that it ''is'' real-world code? It's the yesod backend for [https://www.mythic- beasts.com/auth/register this web page] and I stumbled across this problem simply by trying to upgrade from 7.6 to 7.8. Which brings me to another point: it's great that this will be in 7.10. Is there any chance of getting it into 7.8 too? Most of the distros (Debian, Ubuntu LTS, even Fedora) have not made the jump to 7.8 yet, and when they do I'd hate for anyone else to have the same experience that I did, of a massive slowdown in compile times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 18:37:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 18:37:00 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.c55aba1f18f91a039df09c81aeb3d84d@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: javran Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | newcomer Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by javran): * owner: => javran -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 19:11:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 19:11:13 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.28b56e49c46945d142214009f24e058c@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Comment (by simonmar): @nomeata: great job on these perf improvements! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 20:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 20:34:18 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.a8026d93de07d6246b238374a6cc5b59@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Comment (by thoughtpolice): Joachim, I also picked this last one over to `ghc-7.10`, so these will all hit 7.10.2. @TobyGoodwin - Unfortunately, we aren't going to be doing any more releases of the 7.8.x series at this point, since the branch is quite out of date. In theory, all of the current performance fixes Joachim has made ''should'' apply to the 7.8 branch still, although there will probably be things like conflicts with whitespace and the tabs->spaces conversion that happened. I'm not sure what the policy is for upstream distributions here is, especially if they still aren't even shipping 7.8 to users - and if they aren't, can they not use 7.10? I have no clue what timeline most distros use for upgrading major versions of things like GHC. Luckily, for Debian, Joachim is the maintainer, so I'm sure he'll know the deal. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 18 21:26:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 May 2015 21:26:08 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.712a37ec23e4de3af45635bd5098abb8@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D894 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"eaaa38ba24d5152623cb202a98f71ed09deef0bb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eaaa38ba24d5152623cb202a98f71ed09deef0bb" includes/stg/SMP.h: implement simple load_/store_load_barrier on armv6 and older Assuming there is no real SMP systems on these CPUs I've added only compiler barrier (otherwise write_barrier and friends need to be fixed as well). Patch also fixes build breakage reported in #10244. Signed-off-by: Sergei Trofimovich Reviewers: rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D894 GHC Trac Issues: #10244 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 02:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 02:19:54 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d7ee8c0089f583e37de210cfe858eaf3@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): >It would be unusual to delay a patch-level release for a ticket that has been open for five years. Well, if anything we'd only be holding it up for the specialisation issue posted recently. To me at least it seems like a serious regression so it should probably be fixed in some patch release, whether it's 7.10.2 or 7.10.3 is up to whenever a fix is found. But I also don't want to hold up any other fixes. I wish only to not end up in a situation where the final 7.10.x is released and to get much else in we have to wait for 7.12. As long as it's fixed in 7.10 somewhere, I'm happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 06:26:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 06:26:31 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.0ffe2945b0ba0e518f67653cc6356f88@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791, Phab:D895 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"85bf9e49f5ab4e0681eeda2549dbd4b5faf3ef7f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="85bf9e49f5ab4e0681eeda2549dbd4b5faf3ef7f" Add regression test for #10110. Module C imports a from Module A and b from module B. B does not import anything from A. So if ld is configured to drop DT_NEEDED tags for libraries it does not depend on no DT_NEEDED tag for the temporary shared object containing module A is recorded in the temp SO containing module B. This leads to an undefined symbol when linking the temp SO for module C. Fixes #10110. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D895 GHC Trac Issues: #10110 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 06:26:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 06:26:32 -0000 Subject: [GHC] #10386: Documentation for -Wall is wrong In-Reply-To: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> References: <045.232d0261c427e0e77548f09249f01d5e@haskell.org> Message-ID: <060.ae137649e50aa9acefbb03bc5ee1a2f5@haskell.org> #10386: Documentation for -Wall is wrong -------------------------------------+------------------------------------- Reporter: AlexET | Owner: AlexET Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D889 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5cbac8866e1cf1f5a015e318bf298954b7bf6417/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5cbac8866e1cf1f5a015e318bf298954b7bf6417" user guide: correct documentation for -Wall (fixes #10386) This fixes the documentation for -Wall. As was done previously it leaves out deprecated flags and also fwarn-safe and fwarn-unsafe. I don't know if that was intended or not. -fwarn-safe and fwarn-unsafe are not mentioned on the warnings page at all instead they are mentioned in the safe haskell section. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D889 GHC Trac Issues: #10386 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 06:26:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 06:26:32 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.bff86f20dee438f728162d03f4227eef@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.12.1 Resolution: | Version: Operating System: Unknown/Multiple | Keywords: llvm, Type of failure: None/Unknown | codegen Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D530 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"578d2bad19b3e03fac4da1e5be4b22b73cef0a44/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="578d2bad19b3e03fac4da1e5be4b22b73cef0a44" Remove unneeded compatibility with LLVM < 3.6 Since GHC requires at least LLVM 3.6, some of the special cases (for, e.g., LLVM 2.8 or 2.9) in the LLVM CodeGen can be simply removed. Reviewed By: rwbarton, austin Differential Revision: https://phabricator.haskell.org/D884 GHC Trac Issues: #10074 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 06:26:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 06:26:32 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.8213a0fab51ea41d434b02adec56bb2a@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b0b11ad93cf8470caed572dc16e5cf91304fa355/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b0b11ad93cf8470caed572dc16e5cf91304fa355" In ghci linker, link against all previous temp sos (#10322) The OS X dlopen() appears to only resolve undefined symbols in the direct dependencies of the shared library it is loading. Reviewed By: trommler, austin Differential Revision: https://phabricator.haskell.org/D852 GHC Trac Issues: #10322 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 08:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 08:00:07 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.b695bfbf187091cd8b827cde17be6922@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b199536be25ea046079587933cc73d0a948a0626/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b199536be25ea046079587933cc73d0a948a0626" compiler: make sure we reject -O + HscInterpreted When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 08:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 08:51:35 -0000 Subject: [GHC] #10366: Post link to MacOS binary of 7.10 In-Reply-To: <047.96813fefee3197627308f4e0ad81012c@haskell.org> References: <047.96813fefee3197627308f4e0ad81012c@haskell.org> Message-ID: <062.ab831f276422db3c1238763a351060f9@haskell.org> #10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | thoughtpolice Priority: highest | Status: closed Component: Documentation | Milestone: 7.10.2 Resolution: fixed | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Done! I'm going to deploy Hakyll before 7.10.2, so it will be much easier to keep track of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 08:57:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 08:57:34 -0000 Subject: [GHC] #10432: panic with kind polymorphism Message-ID: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley | Owner: Yakeley | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ExistentialQuantification, PolyKinds, DataKinds, RankNTypes, GADTs, TypeOperators #-} module Bug where import Data.Type.Equality data WrappedType = forall a. WrapType a; matchReflK :: forall (a :: ka) (b :: kb) (r :: *). ('WrapType a :~: 'WrapType b) -> (('WrapType a ~ 'WrapType b) => r) -> r; matchReflK Refl r = r; }}} give this: {{{ Bug.hs:8:15: Couldn't match kind ?ka? with ?kb? ?ka? is untouchable inside the constraints ('WrapType a ~ 'WrapType b) bound by the type signature for matchReflK :: ('WrapType a ~ 'WrapType b) => r at Bug.hs:(8,15)-(9,74)ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: ka_aqv[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I actually think GHC should accept this (and furthermore infer `ka ~ kb`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 08:58:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 08:58:53 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.ccee4dd056be115eb80c1ee16bdeaab5@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"470a94947b076cb74a6adcbcf9b39057a67e1fba/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="470a94947b076cb74a6adcbcf9b39057a67e1fba" Revert "In ghci linker, link against all previous temp sos (#10322)" This reverts commit b0b11ad93cf8470caed572dc16e5cf91304fa355. It apparently made Harbormaster sad. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:22:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:22:34 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.36528754484670a0c5cef368871848b6@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791, Phab:D895 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:23:08 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.bdc88d8383c9fe647af2bd345ba98604@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | performance Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: see ticket | Blocking: | Differential Revisions: Phab:D892 | Phab:D896 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:25:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:25:49 -0000 Subject: [GHC] #10349: ghc-7.10 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) In-Reply-To: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> References: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> Message-ID: <065.96023f4749f738af207e588347b9230c@haskell.org> #10349: ghc-7.10 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) ----------------------------------------+---------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should be fixed, since Phab:D856 and Phab:D858 were both merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:30:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:30:27 -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.8df5a736d1b9435bdb8ada04f5f2a71a@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): 12 months later, and we really have a specific Coercible solver. Do we still need this ticket, which is very vaguely about ?a different solution strategy?? Probably not. Richard, do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:35:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:35:19 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.397ee09b1d75324373be6803a7ea6525@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D894 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: I've merged this to `ghc-7.10` - also, Reid, I committed 753b156dc6b0c38b106c390952750fb800bf27e7 copying your comments from Phab:D894 - so we can hopefully fix the problem you pointed out in the future. We should probably open a bug for this, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:37:23 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds Message-ID: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+------------------------------------- Reporter: | Owner: simonmar thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: high | Version: Component: Runtime | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: arm | Related Tickets: #10244 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As pointed out in #10244 and Phab:D894, the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7: {{{ #elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7) // TODO FIXME: This case probably isn't totally correct - just because we // use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't // mean the binary won't run on a newer ARMv7 system - in which case it // needs a proper barrier. So we should rethink this // - Reid __asm__ __volatile__ ("" : : : "memory"); }}} This is a reminder to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:37:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:37:37 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.b1fa660a2a4bbc4dd7beb62b50c6ca23@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+----------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Revisions: -------------------------------------+----------------------------------- Changes (by thoughtpolice): * owner: simonmar => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:38:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:38:11 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.d72b7ceff1d7261f39114ac12e6e4b09@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D894 Related Tickets: #10433 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: => #10433 Comment: Note: I've filed #10433 as a follow up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 09:45:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 09:45:28 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.8d1989b062babfee43f99d96445c3d6a@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that'd be quite possible. I'm not altogether sure it's worth the bother, but if someone wants to do it (and document it), I'd be OK with that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:03:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:03:41 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.8150ec5e0de4b89ef774061155a53ed8@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D898 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:04:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:04:16 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.6c8228b625480027d1bf5a0a9a8d1868@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => patch * differential: => Phab:D898 * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:25:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:25: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.4e3d97e13555c42e03b2d347e8059c99@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9117 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:38:37 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.d63806654b1b34abe49ce2a73a9be416@haskell.org> #8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8503 #8555 | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: goldfire (added) * status: new => closed * resolution: => fixed Comment: Due to Richards rewrite of the Coercible parser, this now works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:39:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:39:41 -0000 Subject: [GHC] #8799: Orientation of given `Coercible` constraints In-Reply-To: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> References: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> Message-ID: <061.4192437b1fb9f8ab23d625779acfe86e@haskell.org> #8799: Orientation of given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8555 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: goldfire (added) * status: new => closed * resolution: => fixed Comment: Due to Richard?s rewrite of the Coercible parser, this now works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:49:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:49:28 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.ca08838a3d0538f951af30fadfa08e92@haskell.org> #8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8503 #8555 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fc8c5e7a516803c04f2a38b53b9e8beb2066c056/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fc8c5e7a516803c04f2a38b53b9e8beb2066c056" Test Trac #8799, #8555 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 10:49:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 10:49:28 -0000 Subject: [GHC] #8799: Orientation of given `Coercible` constraints In-Reply-To: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> References: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> Message-ID: <061.8ca863de58ae3b8cb53d3ba7b97a84d7@haskell.org> #8799: Orientation of given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8555 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fc8c5e7a516803c04f2a38b53b9e8beb2066c056/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fc8c5e7a516803c04f2a38b53b9e8beb2066c056" Test Trac #8799, #8555 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 11:08:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 11:08:06 -0000 Subject: [GHC] #8799: Orientation of given `Coercible` constraints In-Reply-To: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> References: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> Message-ID: <061.dc8fa182d47eda805f5075103404b59e@haskell.org> #8799: Orientation of given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | typecheck/should_compile/T8799 Related Tickets: #8555 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T8799 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 11:08:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 11:08:50 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.482e4221c821edd3c2be44cf54a5ff08@haskell.org> #8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T8555 Blocked By: | Blocking: Related Tickets: #8503 #8555 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T8555 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 14:57:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 14:57:08 -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.c3d1b770259c2f218f563d5b0ac0b918@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Agreed. This is essentially done. The only part around here that's missing is some theoretical analysis of the new solver. It would be nice, for example, to have a proof that the solver is sound (only produces well-typed coercions) and to figure out what completeness property it has (it's certainly not totally complete). But there's little sense in having a ticket against GHC for that task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 16:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 16:38:14 -0000 Subject: [GHC] #10434: SPECIALISE instance does not specialize as far as SPECIALISE for type signatures Message-ID: <051.7bf13270f831347f83a986154b2317ae@haskell.org> #10434: SPECIALISE instance does not specialize as far as SPECIALISE for type signatures -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs type FreeM c = Reader (FreeEnv c) c class Free' a c where freeVars' :: (Monoid c) => a -> FreeM c instance (Free' a c, Free' b c) => Free' (a,b) c where {-# SPECIALIZE instance (Free' a All, Free' b All) => Free' (a,b) All #-} {-# SPECIALIZE freeVars' :: (Free' a Any, Free' b Any) => (a,b) -> FreeM Any #-} freeVars' (x,y) = freeVars' x `mappend` freeVars' y }}} I would expect these two specialize pragmas to work similarily. However, the interface file shows that the mappend for Any has been inlined, but not the one for All. If you look at the .hi file dump below, you see {{{ Data.Monoid.mappend @ Data.Monoid.All $dMonoid }}} generated by the SPECIALIZE instance, and {{{ case (...) of wild1 { GHC.Types.False -> eta1 `cast` (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N) eta2 GHC.Types.True -> GHC.Types.True }}} generated by the SPECIALIZE for the type signature. For All, mappend is called from the dictionary dMonoid, which is still passed around, whereas for Any, the disjunction has been inlined. {{{ $fFree'(,)c_$s$cfreeVars' :: Agda.TypeChecking.Free.Lazy.Free' a Data.Monoid.All -> Agda.TypeChecking.Free.Lazy.Free' b Data.Monoid.All -> Data.Monoid.Monoid Data.Monoid.All -> (a, b) -> Agda.TypeChecking.Free.Lazy.FreeM Data.Monoid.All {- Arity: 4, HasNoCafRefs, Strictness: , Unfolding: InlineRule (4, True, False) (\ @ a @ b $dFree' :: Agda.TypeChecking.Free.Lazy.Free' a Data.Monoid.All $dFree'1 :: Agda.TypeChecking.Free.Lazy.Free' b Data.Monoid.All $dMonoid :: Data.Monoid.Monoid Data.Monoid.All ds :: (a, b) -> case ds of wild { (,) x y -> let { eta :: Control.Monad.Trans.Reader.ReaderT (Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.All) Data.Functor.Identity.Identity Data.Monoid.All = $dFree' `cast` (Agda.TypeChecking.Free.Lazy.NTCo:Free'[0] _N _N) $dMonoid x } in let { eta1 :: Control.Monad.Trans.Reader.ReaderT (Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.All) Data.Functor.Identity.Identity Data.Monoid.All = $dFree'1 `cast` (Agda.TypeChecking.Free.Lazy.NTCo:Free'[0] _N _N) $dMonoid y } in (\ eta2 :: Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.All -> Data.Monoid.mappend @ Data.Monoid.All $dMonoid (eta `cast` (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N) eta2) `cast` (Data.Functor.Identity.NTCo:Identity[0] _R) (eta1 `cast` (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N) eta2) `cast` (Data.Functor.Identity.NTCo:Identity[0] _R)) `cast` (Trans (_R ->_R Sym (Data.Functor.Identity.NTCo:Identity[0] _R)) (Sym (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N))) }) -} 2292db791a93ca783c0315a38fa7d8f1 $fFree'(,)c_$s$cfreeVars'1 :: Agda.TypeChecking.Free.Lazy.Free' a Data.Monoid.Any -> Agda.TypeChecking.Free.Lazy.Free' b Data.Monoid.Any -> (a, b) -> Agda.TypeChecking.Free.Lazy.FreeM Data.Monoid.Any {- Arity: 3, HasNoCafRefs, Strictness: , Unfolding: InlineRule (3, True, False) (\ $dFree' :: Agda.TypeChecking.Free.Lazy.Free' a Data.Monoid.Any $dFree'1 :: Agda.TypeChecking.Free.Lazy.Free' b Data.Monoid.Any ds :: (a, b) -> case ds of wild { (,) x y -> let { eta :: Control.Monad.Trans.Reader.ReaderT (Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.Any) Data.Functor.Identity.Identity Data.Monoid.Any = $dFree' `cast` (Agda.TypeChecking.Free.Lazy.NTCo:Free'[0] _N _N) Data.Monoid.$fMonoidAny x } in let { eta1 :: Control.Monad.Trans.Reader.ReaderT (Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.Any) Data.Functor.Identity.Identity Data.Monoid.Any = $dFree'1 `cast` (Agda.TypeChecking.Free.Lazy.NTCo:Free'[0] _N _N) Data.Monoid.$fMonoidAny y } in (\ eta2 :: Agda.TypeChecking.Free.Lazy.FreeEnv Data.Monoid.Any -> case (eta `cast` (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N) eta2) `cast` (Data.Functor.Identity.NTCo:Identity[0] (Data.Monoid.NTCo:Any[0])) of wild1 { GHC.Types.False -> eta1 `cast` (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N) eta2 GHC.Types.True -> GHC.Types.True `cast` (Sym (Data.Functor.Identity.NTCo:Identity[0] (Data.Monoid.NTCo:Any[0]))) }) `cast` (Sym (Control.Monad.Trans.Reader.NTCo:ReaderT[0] _R _R _N)) }) -} 2292db791a93ca783c0315a38fa7d8f1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 19:05:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 19:05:25 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 In-Reply-To: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> References: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> Message-ID: <062.e80c70f4712f0fe04aaed8ea64e66ab8@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Phab:D894 Related Tickets: #10433 | -------------------------------------+------------------------------------- Comment (by rwbarton): Looks good, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 19:37:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 19:37:36 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure In-Reply-To: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> References: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> Message-ID: <066.13b0ff54113dca4325b685003fe3d2ba@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"25d1a716395e349736994759d1fcbb3721f3ee9f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="25d1a716395e349736994759d1fcbb3721f3ee9f" Fix error messages from open(Binary)TempFileWithDefaultPermissions Fixes Trac #10430. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 19:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 19:38:29 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure In-Reply-To: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> References: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> Message-ID: <066.0ffd8a4f4de028c59c166de77da86000@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge Comment: Thanks. I just pushed this change directly since it's quite trivial. Austin, please merge if desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 21:50:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 21:50:33 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.7d6118a54d1627f53387fce29242df60@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9263 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): I am getting a similar error (with ghc 7.8.3) when compiling Agda for the second time (without removing dist). Probably cause is SPECIALIZE pragmas. https://github.com/agda/agda/commit/22eb932c0df278e40e40c6e990d2e9dcb6f99449 Probably reproducible by * cloning Agda at this commit * introduce an error in a later module, e.g. src/full/Agda/TypeChecking/InstanceArguments.hs * make install-bin * fix the error * make install-bin Error: {{{ The interface for ?Agda-2.4.3:Agda.TypeChecking.Free.Lazy? Rule SPEC $cfreeVars': Iface type variable out of scope: a Cannot continue after interface file error cabal: Error: some packages failed to install: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 21:56:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 21:56:33 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.c3399c07aafaf1b82f13ad30bde70374@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9263 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Do you get the error with 7.10? We are unlikely to release another version of 7.8, unless it's mission critical to a significant chunk of users. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 19 22:57:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 May 2015 22:57:38 -0000 Subject: [GHC] #10423: Can't infer Monad n from (Monad m, m ~ n) In-Reply-To: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> References: <048.3e83406c51a5eb88b203e755f864fc07@haskell.org> Message-ID: <063.32481cc7a0982aa2ca10b73857001922@haskell.org> #10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This is my fault, fallout from my removal of "silent superclasses". I understand what is happening here. It is clearly a bug. I think that if you replace {{{ instance (Monad m, m ~ n) => Testable n (Property m) where }}} by putting `Monad n` in the context, thus {{{ instance (Monad n, m ~ n) => Testable n (Property m) where }}} it'll probably work. It'll be a couple of weeks before I can actually fix it. Thanks very much for the report. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 09:07:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 09:07:49 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.bad229dd9bdbf1b2f06cfb9de1a6afff@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This works in HEAD, but another variant makes HEAD, too, fail in the same way `No skolem info`: {{{ matchReflK2 :: forall (a :: ka) (b :: kb) (r :: *). ('WrapType a :~: 'WrapType b) -> r matchReflK2 x = let foo :: ('WrapType a ~ 'WrapType b) => r foo = undefined in undefined }}} Reason: the type of `foo` mentions `a`, `b`, `r` as free variables; the ambiguity check doesn't bind them; the error message generator falls over. Need to look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 09:11:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 09:11:52 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 Message-ID: <047.bc42599240078110c16528fec3996433@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Windows Keywords: windows, | Type of failure: Runtime crash exceptions | Blocked By: Architecture: x86 | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We have found a very strange RTS bug that only manifests on some Windows machines, running Windows Server 2008 R2. It does not occur on our Windows 7 machines. We are not sure whether the installed version of Visual C runtime system matters. The context is a ghc-compiled executable, that calls a function from a C++ DLL. The C++ function throws an exception internally, then catches it, and returns normally. The symptom of the bug is that, from ghc-7.8.1 onwards, including ghc-7.10.1, the C++ exception is not caught by the C++ code, but terminates the program catastrophically, with exit code 127. When the Haskell executable is compiled by ghc-7.2.3 or before, the bug does not happen. If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows. Attached to the ticket, please find (a) a C++ module, which exports a single function that throws an exception and catches it; (b) a Haskell module which imports the C++ via the FFI, and calls it; (c) a build script which compiles the C++ to a DLL, using the MSVC compiler, compiles the Haskell with ghc, and links them together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 09:24:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 09:24:25 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.ee296bce228c9212463154a8501e8dc6@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): Correction: I meant to say that the bug does not appear with ghc-7.6.3 and below. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 12:00:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 12:00:51 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.730707d0ed7b6fcebc9d0ba0dc0a5c23@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by malcolmw): Here is the expected output, on a Windows 7 machine: {{{ $ ./TestExceptions.exe 1 Called foo() with bar=0 $ echo $? 0 }}} And here is the unexpected output, on a Windows 2008 R2 machine: {{{ $ ./TestExceptions.exe $ echo $? 127 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 12:43:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 12:43:51 -0000 Subject: [GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 In-Reply-To: <047.bc42599240078110c16528fec3996433@haskell.org> References: <047.bc42599240078110c16528fec3996433@haskell.org> Message-ID: <062.4dac249f7a811984ef7a8213f0d9f32b@haskell.org> #10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: windows, Operating System: Windows | exceptions Type of failure: Runtime crash | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 14:59:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 14:59:21 -0000 Subject: [GHC] #8171: Extending ExtendedDefaultRules In-Reply-To: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> References: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> Message-ID: <060.594ad8dfeb1188eebde4feef4c9d38ad@haskell.org> #8171: Extending ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: ekmett | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 15:01:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 15:01:34 -0000 Subject: [GHC] #8171: Extending ExtendedDefaultRules In-Reply-To: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> References: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> Message-ID: <060.95cab716eba0504af28a2accad5a2505@haskell.org> #8171: Extending ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: ekmett | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kanetw): I'll be taking a look at this. Probably going to write a paper about the implementation, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 16:24:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 16:24:41 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.7012f49c4803564c56e1ccf407f2b76d@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D638 -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 20 23:49:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 May 2015 23:49:31 -0000 Subject: [GHC] #10436: Excessive numbers of packages loaded for TH Message-ID: <045.b8bbf0247835752ace9434694fd31689@haskell.org> #10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases: {{{ ghc --make Blah.hs }}} vs {{{ ghc --make Blah.hs -package foo }}} In the first case, ghc will work out for itself which packages it needs to load to run the TH code in `Blah.hs` while in the second case, ghc will unconditionally load package `foo` in addition to anything else. Why is this a problem? Consider a real example (reported on IRC): {{{ ghc --make Main.hs [1 of 4] Compiling Uplink ( Uplink.hs, Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [3 of 4] Compiling Joystick ( Joystick.hs, Joystick.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... }}} This just loads `base` and its deps. Great, it works. Now the exact same `Main.hs` built by cabal (which of course uses `-package-id` flags): {{{ cabal build Building jpl-0.1.0.0... Preprocessing executable 'jpl' for jpl-0.1.0.0... [1 of 4] Compiling Uplink ( Uplink.hs, dist\build\jpl\jpl- tmp\Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, dist\build\jpl\jpl- tmp\FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package SHA-1.6.4.2 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. }}} ... snip a further 80, '''yes 80 packages''' ... {{{ Loading package linear-1.18.0.1 ... linking ... done. Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0' ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup }}} ... snip more boring details of the linker errors ... So yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place. So the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider `-package` flags to be instructions to load these packages for running TH code. As a bonus it'll be quicker and our build output shorter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 00:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 00:25:12 -0000 Subject: [GHC] #10436: Excessive numbers of packages loaded for TH In-Reply-To: <045.b8bbf0247835752ace9434694fd31689@haskell.org> References: <045.b8bbf0247835752ace9434694fd31689@haskell.org> Message-ID: <060.c49f3ca5c7d54c9dc92604b33b95edea@haskell.org> #10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I thought there was a ticket which caused us to link `-package` eagerly, but this code is actually quite old: {{{ commit ef5b4b146aa172d8ac10f39b5eb3d7a0f948d8f1 Author: simonmar Date: Fri Nov 26 16:22:13 2004 +0000 [project @ 2004-11-26 16:19:45 by simonmar] Further integration with the new package story. GHC now supports pretty much everything in the package proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 01:33:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 01:33:12 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.e284499d514017c2e059ab7ad3935db5@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Valgrind has zero complaints before the program segfaults. Now looking to dump the state of the stack around problem code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 07:27:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 07:27:10 -0000 Subject: [GHC] #10437: RunHaskell error in HSExtra on Win64 Message-ID: <052.aa77c29a6e025461dfccfc1392459b8c@haskell.org> #10437: RunHaskell error in HSExtra on Win64 -------------------------------------+------------------------------------- Reporter: | Owner: ScottSedgwick | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Operating System: Windows Keywords: runhaskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I ran the following command, and got this error: {{{ $ runhaskell shakefile.hs clean shakefile.hs: C:\Users\Scott Sedgwick\AppData\Roaming\cabal\x86_64 -windows-ghc-7.8.3\extra-1.2\HSextra-1.2.o: Not x86_64 PEi386 shakefile.hs: shakefile.hs: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Scott Sedgwick\\AppData\\Roaming\\cabal\\x86_64-windows- ghc-7.8.3\\extra-1.2\\HSextra-1.2.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The shakefile in question looks like this: {{{ import Development.Shake import Development.Shake.FilePath --import System.Info srcFiles = [ "source/main.hs", "source/DBDataStructures.hs", "source/FormatDBData.hs", "source/GetDBData.hs", "source/ParseDBData.hs"] exeFile = "dist/build/mssql-er/mssql-er.exe" depFiles = [ "dependencies/erd/erd.exe", "dependencies/dot/Pathplan.dll", "dependencies/dot/config6", "dependencies/dot/gvc.dll", "dependencies/dot/iconv.dll", "dependencies/dot/libfontconfig-1.dll", "dependencies/dot/libgmodule-2.0-0.dll", "dependencies/dot/libpango-1.0-0.dll", "dependencies/dot/libpangowin32-1.0-0.dll", "dependencies/dot/ltdl.dll", "dependencies/dot/cdt.dll", "dependencies/dot/dot.exe", "dependencies/dot/gvplugin_dot_layout.dll", "dependencies/dot/libcairo-2.dll", "dependencies/dot/libfreetype-6.dll", "dependencies/dot/libgobject-2.0-0.dll", "dependencies/dot/libpangocairo-1.0-0.dll", "dependencies/dot/libpng14-14.dll", "dependencies/dot/zlib1.dll", "dependencies/dot/cgraph.dll", "dependencies/dot/freetype6.dll", "dependencies/dot/gvplugin_pango.dll", "dependencies/dot/libexpat.dll", "dependencies/dot/libglib-2.0-0.dll", "dependencies/dot/libgthread-2.0-0.dll", "dependencies/dot/libpangoft2-1.0-0.dll", "dependencies/dot/libxml2.dll"] copyDep :: FilePath -> Action() copyDep src = do let dst = "dist" (dropDirectory1 (dropDirectory1 src)) copyFile' src dst main :: IO() main = shakeArgs shakeOptions $ do want ["deploy"] "clean" ~> do cmd "cabal" "clean" "dist/setup-config" *> \_ -> do need ["mssql-er.cabal"] cmd "cabal" "configure" "--enable-tests" "configure" ~> do need ["dist/setup-config"] exeFile *> \_ -> do need (["configure"] ++ srcFiles) cmd "cabal" "build" "build" ~> do need [exeFile, "test"] "test" ~> do need srcFiles cmd "cabal" "test" "deploy" ~> do need ["build"] mapM_ copyDep depFiles }}} Strangely, if I compile that shakefile using ghc, then run it, it works correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 12:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 12:13:46 -0000 Subject: [GHC] #10363: ApiAnnotations : HsForAllTy discards parens In-Reply-To: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> References: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> Message-ID: <059.5f3f593e57cdb8d68f5ca369231c9b6f@haskell.org> #10363: ApiAnnotations : HsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: #10315,#10354,#10278 | Blocking: | Differential Revisions: Phab:D836 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c553e980e4a5d149af13bb705ec02819a15937ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c553e980e4a5d149af13bb705ec02819a15937ee" ApiAnnotations : AST version of nested forall loses forall annotation Summary: When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined the parser creates nested HsForAllTy's for the two forall statements. These get flattened into a single one in `HsTypes.mk_forall_ty` This patch removes the flattening, so that API Annotations are not lost in the process. Test Plan: ./validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: bgamari, mpickering, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D836 GHC Trac Issues: #10278, #10315, #10354, #10363 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 12:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 12:13:46 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.b38090e2e2faead4b3d6a89a94d6840a@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c553e980e4a5d149af13bb705ec02819a15937ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c553e980e4a5d149af13bb705ec02819a15937ee" ApiAnnotations : AST version of nested forall loses forall annotation Summary: When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined the parser creates nested HsForAllTy's for the two forall statements. These get flattened into a single one in `HsTypes.mk_forall_ty` This patch removes the flattening, so that API Annotations are not lost in the process. Test Plan: ./validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: bgamari, mpickering, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D836 GHC Trac Issues: #10278, #10315, #10354, #10363 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 12:13:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 12:13:47 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.7285928361d301d3d35f37bf99bc4bb8@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: Phab:D836 | Phab:D868 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c553e980e4a5d149af13bb705ec02819a15937ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c553e980e4a5d149af13bb705ec02819a15937ee" ApiAnnotations : AST version of nested forall loses forall annotation Summary: When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined the parser creates nested HsForAllTy's for the two forall statements. These get flattened into a single one in `HsTypes.mk_forall_ty` This patch removes the flattening, so that API Annotations are not lost in the process. Test Plan: ./validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: bgamari, mpickering, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D836 GHC Trac Issues: #10278, #10315, #10354, #10363 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 12:13:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 12:13:47 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.21e70c58c33023f6ecbadb7721d28ba9@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | Phab:D833,Phab:D836 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c553e980e4a5d149af13bb705ec02819a15937ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c553e980e4a5d149af13bb705ec02819a15937ee" ApiAnnotations : AST version of nested forall loses forall annotation Summary: When parsing {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined the parser creates nested HsForAllTy's for the two forall statements. These get flattened into a single one in `HsTypes.mk_forall_ty` This patch removes the flattening, so that API Annotations are not lost in the process. Test Plan: ./validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: bgamari, mpickering, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D836 GHC Trac Issues: #10278, #10315, #10354, #10363 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 13:05:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 13:05:52 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.4c6937c22d21a2d93464f8fb1a3e8515@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"0df14b5db06751f817d3ba794cc74ac54519b5b8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0df14b5db06751f817d3ba794cc74ac54519b5b8" ApiAnnotations : parens around a context with wildcard loses annotations Summary: In the following code, the extra set of parens around the context end up with detached annotations. {-# LANGUAGE PartialTypeSignatures #-} module ParensAroundContext where f :: ((Eq a, _)) => a -> a -> Bool f x y = x == y Trac ticket #10354 It turns out it was the TupleTy that was the culprit. This may also solve #10315 Test Plan: ./validate Reviewers: hvr, austin, goldfire Reviewed By: austin Subscribers: goldfire, bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D868 GHC Trac Issues: #10354, #10315 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 13:05:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 13:05:52 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.b98da703aaf084d1b87c7b957be0211b@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: Phab:D836 | Phab:D868 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"0df14b5db06751f817d3ba794cc74ac54519b5b8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0df14b5db06751f817d3ba794cc74ac54519b5b8" ApiAnnotations : parens around a context with wildcard loses annotations Summary: In the following code, the extra set of parens around the context end up with detached annotations. {-# LANGUAGE PartialTypeSignatures #-} module ParensAroundContext where f :: ((Eq a, _)) => a -> a -> Bool f x y = x == y Trac ticket #10354 It turns out it was the TupleTy that was the culprit. This may also solve #10315 Test Plan: ./validate Reviewers: hvr, austin, goldfire Reviewed By: austin Subscribers: goldfire, bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D868 GHC Trac Issues: #10354, #10315 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 21 13:48:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 May 2015 13:48:12 -0000 Subject: [GHC] #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind In-Reply-To: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> References: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> Message-ID: <059.220e6e6672091d044f914c0f34c68c74@haskell.org> #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c488da851c39ca202cdd056091176acbabdd7dd4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c488da851c39ca202cdd056091176acbabdd7dd4" ApiAnnotatons : AnnDcolon in wrong place for PatBind Summary: In the following code fragment let ls :: Int = undefined the `::` is attached to the ls function as a whole, rather than to the pattern on the LHS. Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D883 GHC Trac Issues: #10396 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 00:52:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 00:52:41 -0000 Subject: [GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings Message-ID: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE TypeFamilies #-} module Bad where foo f = g where g r = x where x :: _ x = r }}} When compiled, it produces the following output: {{{ [1 of 1] Compiling Bad ( src/Bad.hs, src/Bad.o ) src/Bad.hs:8:22: Warning: Found hole ?_? with type: w_1 Where: ?w_1? is a rigid type variable bound by the inferred type of g :: w_1 -> w_1 at src/Bad.hs:7:9 Relevant bindings include r :: w_1 (bound at src/Bad.hs:7:11) g :: w_1 -> w_1 (bound at src/Bad.hs:7:9) f :: t (bound at src/Bad.hs:6:5) foo :: t -> w_ -> w_ (bound at src/Bad.hs:6:1) In the type signature for ?x?: _ In an equation for ?g?: g r = x where x :: _ x = r In an equation for ?foo?: foo f = g where g r = x where x :: _ x = r ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): StgCmmEnv: variable not found x_alC local binds for: f_sv5 r_sv6 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 04:39:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 04:39:45 -0000 Subject: [GHC] #10439: Opt_ImplicitImportQualified doesn't work for constructor field name Message-ID: <046.7eeda0ab82b2b7fc80cf5d3190f2c3b2@haskell.org> #10439: Opt_ImplicitImportQualified doesn't work for constructor field name -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: GHC rejects Test Case: | valid program Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- {{{#!hs -- ghci -fimplicit-import-qualified Prelude> let tree = Data.Tree.Node 0 [] Prelude> Data.Tree.rootLabel tree 0 Prelude> let f i j = i { Data.Tree.rootLabel = j } :4:17: ?Data.Tree.rootLabel? is not a (visible) constructor field name Prelude> import qualified Data.Tree Prelude Data.Tree> let f i j = i { Data.Tree.rootLabel = j } Prelude Data.Tree> f tree 1 Node {rootLabel = 1, subForest = []} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 05:08:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 05:08:46 -0000 Subject: [GHC] #10439: Opt_ImplicitImportQualified doesn't work for constructor field name In-Reply-To: <046.7eeda0ab82b2b7fc80cf5d3190f2c3b2@haskell.org> References: <046.7eeda0ab82b2b7fc80cf5d3190f2c3b2@haskell.org> Message-ID: <061.11b06ad28773a343dd62d5e394527fde@haskell.org> #10439: Opt_ImplicitImportQualified doesn't work for constructor field name -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D900 Related Tickets: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D900 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 07:22:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 07:22:10 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.ef4b5ca13ec2b3d81c714c7698727924@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Using the gdb macros on the wiki I can retrieve the following info after the segfault: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb14ff460 (LWP 7214)] 0xb88d09d4 in ?? () (gdb) bt #0 0xb88d09d4 in ?? () #1 0x70000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) pregs $1 = {rR1 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} ,rR2 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR3 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR4 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR5 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR6 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR7 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR8 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR9 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rR10 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} , rF1 = 0, rF2 = 0, rF3 = 0, rF4 = 0, rF5 = 0, rF6 = 0 , rD1 = 0, rD2 = 0, rD3 = 0, rD4 = 0, rD5 = 0, rD6 = 0 , rXMM1 = {h = 0, l = 0} , rXMM2 = {h = 0, l = 0} , rXMM3 = {h = 0, l = 0} , rXMM4 = {h = 0, l = 0} , rXMM5 = {h = 0, l = 0} , rXMM6 = {h = 0, l = 0} , rYMM1 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rYMM2 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rYMM3 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rYMM4 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rYMM5 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rYMM6 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} , rZMM1 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rZMM2 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rZMM3 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rZMM4 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rZMM5 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rZMM6 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} , rL1 = 0, rSp = 0x0, rSpLim = 0x0, rHp = 0x0, rHpLim = 0xb08fbfff , rCCCS = 0x0, rCurrentTSO = 0xb09cc8a4, rNursery = 0x109078 , rCurrentNursery = 0xb0801f60, rCurrentAlloc = 0xb0901980, rHpAlloc = 0, rRet = 3} (gdb) ptso $2 = {header = {info = 0xb2bf43c0 }, _link = 0xb2c146d8 , global_link = 0xb2c146d8 , stackobj = 0xb09cc4f4, what_next = 1, why_blocked = 0, flags = 0 , block_info = {closure = 0xb2c146d8 , prev = 0xb2c146d8 , bh = 0xb2c146d8 , throwto = 0xb2c146d8 , wakeup = 0xb2c146d8 , fd = -1295956264 } , id = 22, saved_errno = 0, dirty = 1 , bound = 0x0, cap = 0xb2c16180 , trec = 0xb2c146d0 , blocked_exceptions = 0xb2c146d8 , bq = 0xb2c146d8 , alloc_limit = 2592, tot_stack_size = 232 } (gdb) info registers r0 0xb6f73018 3069653016 r1 0xb2bf434c 2998879052 r2 0x1 1 r3 0xb09cc7c6 2963064774 r4 0xb2c16190 2999017872 r5 0xb09cc81c 2963064860 r6 0xb08fbbf4 2962209780 r7 0xb09cc938 2963065144 r8 0xb14fefa0 2974805920 r9 0x0 0 r10 0xb2bf4160 2998878560 r11 0xb09cc558 2963064152 r12 0xb2c15b8c 2999016332 sp 0xb14fcd68 0xb14fcd68 lr 0x70000000 1879048192 pc 0xb88d09d4 0xb88d09d4 cpsr 0x400f0010 1074724880 }}} The `pc` register definitetly does contain a bad value, but there's no good explanation of how it got there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 08:21:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 08:21:04 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6c19f40d1bd4aca68e8148b49ee477e4@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by bgamari): Okay. For the record, you are using a statically linked GHC, yes (`DYNAMIC_GHC_PROGRAMS=NO` I believe)? Perhaps you could set a breakpoint at `rts/Schedule.c:460` and have a look at `stg_returnToStackTop` and `cap`? -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Fri May 22 11:26:22 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Fri, 22 May 2015 15:26:22 +0400 Subject: error in 7.10.1 ? Message-ID: <1432293982.2877.51.camel@one.mechvel.pereslavl.ru> Dear GHC developers, The confirmation token letter from the bug tracker travels too long, I do not know, why. Meanwhile I cannot report there. So, I report it in the below way: http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may22-2015.zip Make it, please, with ghc-7.10.1 as it is written there in install.txt, including making demotest/Main. Then ./Main breaks in the middle reporting a DoCon application error ---------------------------------------------------------------------------- Factorization in K1[x], K1 a generic finite extension of a prime field K = Z/(p) .. factor f, f = (x^10 + x^7 + x^5 + x^3 + x^2 + (2)*x+ (2)) <- K[x] = ((Z/<5>)["t"]/<(t^3 + 4*t + 3)>)["x"] Domain term of K must contain a Finite field description. --------------------------------------------------------------------------- I obtain this for ghc-7.10.1 made from source by ghc-7.8.2 on Debian Linux, x-86, 64 bit. The story is as follows. docon-2.12 http://www.botik.ru/pub/local/Mechveliani/docon/2.12/ has been tested under ghc-7.8.2, and it works. Now I am trying to port it to ghc-7.10.1. This needs inserting certain pragmas for OVERLAPPING/OVERLAPPABLE into some instance declarations. So I call this port docon-2.12.1. 7.10.1-errReport-may22-2015.zip is the error report of docon-2.12.1 to ghc-7.10.1. This application has the OVERLAPPABLE pragma set to one instance and the OVERLAPPING pragma set to many instances. GHC itself warns of overlaps. Then I 1) set the pragma to the reported instance (pair), 2) recompile the corresponding module 3) rerun make configure; make build. This process has finished in `making' the application. Then, > cd demotest > ghc $doconCpOpt -O --make -rtsopts Main > ./Main produces the above error instead of the test success report. I suspect that the reason is in treating the instance overlaps (but there may be another source). Comparing docon-2.12 + ghc-7.8.2 to 7.10.1-errReport-may22-201 + ghc-7.10.1, can you, please, find: how to fix the latter version? Is this a bug in ghc-7.10.1 ? Regards, -------- Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Fri May 22 12:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 12:32:31 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.b4e54975dcf6a098c921297673f4a058@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): Will adding `-j9` to the `ghc-options:` field of a cabal project mitigate this in the mean time until this is fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 13:11:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 13:11:35 -0000 Subject: [GHC] #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind In-Reply-To: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> References: <044.e2a8944c5582fbf9931e76b79e60f7d0@haskell.org> Message-ID: <059.a4c5225de889038fc41e2532cf690e10@haskell.org> #10396: ApiAnnotatons : AnnDcolon in wrong place for PatBind -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D883 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * differential: => Phab:D883 * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 13:12:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 13:12:12 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.3f319f0237f680476801d4ebc805e7cc@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315,#10354 | Test Case: | Blocking: | Differential Revisions: Phab:D868 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 13:12:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 13:12:42 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.af6228189fd4f3cbd6cdfb0a46f4f1cd@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | Phab:D833,Phab:D836 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:14:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:14:31 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.4d8e28e952ca27fa3e29b5540b8a871a@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c89bd681d34d3339771ebdde8aa468b1d9ab042b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c89bd681d34d3339771ebdde8aa468b1d9ab042b" Fix quadratic behaviour in tidyOccName In the test program from comment:3 of Trac #10370, it turned out that 25% of all compile time was going in OccName.tidyOccName! It was all becuase the algorithm for finding an unused OccName had a quadratic case. This patch fixes it. THe effect is pretty big: Before: total time = 34.30 secs (34295 ticks @ 1000 us, 1 processor) total alloc = 15,496,011,168 bytes (excludes profiling overheads) After total time = 25.41 secs (25415 ticks @ 1000 us, 1 processor) total alloc = 11,812,744,816 bytes (excludes profiling overheads) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:14:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:14:32 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.44c90631a83dccc081e4a50c8d98df19@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45d9a15c4b85a2ed89579106bdafd84accf2cb39/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="45d9a15c4b85a2ed89579106bdafd84accf2cb39" Fix a huge space leak in the mighty Simplifier This long-standing, terrible, adn somewhat subtle bug was exposed by Trac #10370, thanks to Reid Barton's brilliant test case (comment:3). The effect is large on the Trac #10370 test. Here is what the profile report says: Before: total time = 24.35 secs (24353 ticks @ 1000 us, 1 processor) total alloc = 11,864,360,816 bytes (excludes profiling overheads) After: total time = 21.16 secs (21160 ticks @ 1000 us, 1 processor) total alloc = 7,947,141,136 bytes (excludes profiling overheads) The /combined/ effect of the tidyOccName fix, plus this one, is dramtic for Trac #10370. Here is what +RTS -s says: Before: 15,490,210,952 bytes allocated in the heap 1,783,919,456 bytes maximum residency (20 sample(s)) MUT time 30.117s ( 31.383s elapsed) GC time 90.103s ( 90.107s elapsed) Total time 120.843s (122.065s elapsed) After: 7,928,671,936 bytes allocated in the heap 52,914,832 bytes maximum residency (25 sample(s)) MUT time 13.912s ( 15.110s elapsed) GC time 6.809s ( 6.808s elapsed) Total time 20.789s ( 21.954s elapsed) - Heap allocation halved - Residency cut by a factor of more than 30. - ELapsed time cut by a factor of 6 Not bad! The details ~~~~~~~~~~~ The culprit was SimplEnv.mkCoreSubst, which used mapVarEnv to do some impedence-matching from the substitituion used by the simplifier to the one used by CoreSubst. But the impedence-mactching was recursive! mk_subst tv_env cv_env id_env = CoreSubst.mkSubst in_scope tv_env cv_env (mapVarEnv fiddle id_env) fiddle (DoneEx e) = e fiddle (DoneId v) = Var v fiddle (ContEx tv cv id e) = CoreSubst.substExpr (mk_subst tv cv id) e Inside fiddle, in the ContEx case, we may do another whole level of fiddle. And so on. Moreover, UniqFM (which is built on Data.IntMap) is strict, so the fiddling is done eagerly. I didn't wok through all the details but the result is a gargatuan blow-up of entirely unnecessary work. Laziness would make this go away, I think, but I don't want to mess with IntMap. And in any case, the impedence matching is a royal pain. In the end I simply ceased trying to use CoreSubst.substExpr in the simplifier, and instead just use simplExpr. That does mean bit of duplication; e.g. new code for simplRules. But it's not a big deal and it's far more direct and easy to reason about. A bit of knock-on refactoring: * Data type ArgSummary moves to CoreUnfold. * interestingArg moves from CoreUnfold to SimplUtils, and gets a SimplEnv argument which can be used when we encounter a variable. * simplLamBndrs, addBndrRules move from SimplEnv to Simplify (because they now calls simplUnfolding, simplRules resp) * SimplUtils.substExpr, substUnfolding, mkCoreSubst die completely * In Simplify some several functions that were previously pure substitution-based functions are now monadic: - addBndrRules, simplRule - addCoerce, add_coerce in simplCast * In case 2c of Simplify.rebuildCase, there was a pretty disgusting expression-substitution taking place for 'rhs'; and we really don't want to make that monadic becuase 'rhs' can be big. Solution: reduce the arity of the rules for seq. See Note [User-defined RULES for seq] in MkId. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:20:50 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.154799b5eeec1c58ae69a33c3d4e4759@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The commit messages tell the story. Reid's example in comment:3 showed up TWO separate, substantial non-linear performance holes in GHC, both of which I have now fixed. Reid, your example was amazingly helpful. '''Austin''' I have not added a `perf/compiler` test case. Could you do so please? I wasn't sure that a 20-second compile time was acceptable. I'm leaving the ticket open for that reason. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:22:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:22:23 -0000 Subject: [GHC] #10440: Float out just gets floated in Message-ID: <046.50e304ea433849ae9a4eff8a12fa38d8@haskell.org> #10440: Float out just gets floated in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Ihe test case in comment:3 of #10370 I found that huge numbers of sub- expressions were getting floated to top level by float-out, and then inlined straight back in. This is a big waste of time. Not hard to fix; this ticket is to remind me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:39:32 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.4fed770de45b8a2f0bb1dcd616afdab6@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge * milestone: => 7.10.2 Comment: Yeah, so we want something smaller, we don't need the 20 second variant. We can probably just cut Reid's test case in half or even a third and check that in, double checking the behavior is still fixed (which is obviously pretty easy). I'll get on it shortly. I'm also moving this to 7.10.2 - the `tidyOccName` fix already applies cleanly in my tree. The evil simplifier bug applies modulo a small change in `SimplCore` - so this is an excellent bugfix to go in! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 14:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 14:46:47 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure In-Reply-To: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> References: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> Message-ID: <066.552affc1779eefef9daf550cd6d4072b@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.2 Comment: Easy fix, moving to 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 22 19:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 May 2015 19:06:17 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.853fc39b267710a8463caf0ff6980c8c@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9263 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by andreas.abel): This issue nudged me to install ghc 7.10. With 7.10, this problem does not occur. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 00:32:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 00:32:51 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.15cc024eb465b3e66858bcf360e40b6f@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): This is definitely not statically linked (the `lld` command shows dynamically linked Haskell libraries like `haskeline`, `terminfo`, `transformers` as well as the usual C library suspects. Debugging this in GDB is *really* difficult. Firstly, I can only recreate the problem when running with `--interactive`. Secondly, GDB and `ghc- stage2 --interactive` both try to take control of the same terminals so I have to start the `ghc-stage2 --interactive` process and connect gdb to it with `gdb -p $(pidof ghc-stage2)`. The `.gchi` file contains: {{{ putStr "Continue ... " _ <- getChar putStrLn "ok" data X = Y deriving Eq Y == Y }}} The `getChar` is there to pause the `ghc-stage2` process long enough to attach GDB. Unfortunately, this means that the number of passes through the code I'm trying to debug is not deterministic which makes setting a breakpoint rather difficult. I am currently playing around with replacing `getChar` with `threadDelay` to see if I can make it determinisitc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 01:07:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 01:07:03 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.cd21966aa80911f87b87fbd6016c06ab@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Even switching to using `threadDelay` doesn't make it deterministic under GDB, but it is deterministic when just run at the command line. Giving up on GDB because it has a Heisenberg-like effect on the problem. Will need to debug this with `printf`. If I add a `statc int` variable in the `case ThreadRunGHC` block and increment it every time the code passes through this block and I run it at the command line, the count gets to 152 or 153 before the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 04:09:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 04:09:43 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations Message-ID: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is: {{{ cd ./typecheck/should_compile && "C:/msys64/home/ezy.exe" -c tc055.hs -fforce-recomp -dcore-lint -dcmm-lib -rtsopts -fno-warn-tabs -fno-ghci- history -fno-warnrr 2>&1 '..\timeout\install-inplace\bin\timeout.exe" "300" "cexternal command, operable program or batch file. Compile failed (status 256) errors were: }}} I have diagnosed the problem to the fact that we are passing a complex command string to cmd with adequately quoting it. In particular, when I inspect the command line that Python is attempting to invoke, it looks something like this: {{{ cmd \c 'timeout.exe 300 "cd . && "inplace/ghc-stage2" -c blah blah"' }}} Notice, in particular, that the quoted GHC executable was not inside the timeout invocation is not double-quoted, so cmd does NOT parse the command the way you want it to. Curiously enough, when I remove this fix (introduced by commit `101c62e26286353dd3fac1ef54323529b64c9902`), the msys Python runner works fine. So I don't even know what this commit was intended to fix; it seems to have done more harm than good Here are some details about my configuration: {{{ ezyang at cutlass MSYS ~/ghc-validate/testsuite $ python2 --version Python 2.7.9 ezyang at cutlass MSYS ~/ghc-validate/testsuite $ bash --version GNU bash, version 4.3.33(3)-release (x86_64-pc-msys) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 04:15:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 04:15:02 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.d2b12dfee7dee8a490d227215665cc5e@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): See #10441 for this apparently breaking in a recent version of msys2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 04:21:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 04:21:32 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.0f7d2f3dcf6b01930ca388cd4b7185a0@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Oh yeah, my msys2 build is apparently 20150202. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 05:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 05:42:13 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.0fe525590db383d37a33d2e244de712e@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Oh, here is a more accurate report from pacman -Q {{{ msys2-keyring r8.3864337-1 msys2-runtime 2.1.0.16351.cd3184b-1 msys2-runtime-devel 2.1.0.16351.cd3184b-1 msys2-w32api-headers 5.0.0.4456.c8b6742-1 msys2-w32api-runtime 5.0.0.4455.32db221-1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 06:32:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 06:32:01 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant In-Reply-To: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> References: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> Message-ID: <063.f697c7b62ec46e3ce4dc75e39f5a0195@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: JohnWiegley, gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 06:32:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 06:32:20 -0000 Subject: [GHC] #10411: Neighbour let-bindings are not reported as relevant In-Reply-To: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> References: <048.a8f04c7059c150a3c9259acc7ab2289a@haskell.org> Message-ID: <063.d31e363033424eca54f851404ba81912@haskell.org> #10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gershomb): Sorry for the noise, this is a test comment to poke the trac mail system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 07:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 07:50:22 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.ad755e403864ecd09235085bb77f2f30@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D901 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: => Phab:D901 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 12:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 12:34:24 -0000 Subject: [GHC] #9219: Parallel build proceeds despite errors In-Reply-To: <048.2de32bbd0472065d8e68806efc98b66c@haskell.org> References: <048.2de32bbd0472065d8e68806efc98b66c@haskell.org> Message-ID: <063.0c1210f22dc0e552376401c4ff74261f@haskell.org> #9219: Parallel build proceeds despite errors -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Related [http://www.gnu.org/software/make/manual/make.html make] issues: * [http://savannah.gnu.org/bugs/?41781 41781]: Provide a fast fail path when a target is compromized during a parallel build * [http://savannah.gnu.org/bugs/?39146 39146]: Indicate error upon termination in case of parallel jobs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 16:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 16:17:30 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic In-Reply-To: <051.41ace47270d90cc9e836ab3706638147@haskell.org> References: <051.41ace47270d90cc9e836ab3706638147@haskell.org> Message-ID: <066.a9942080768d6879d8de3e5c0e3bf1e8@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 16:54:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 16:54:03 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.d3ce8614d12c8d95b099699a9585fd07@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erdeszt): * owner: => erdeszt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 19:56:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 19:56:08 -0000 Subject: [GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1 Message-ID: <053.4e92c64eaf9746f8729380756df319fb@haskell.org> #10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose that I have : {{{#!hs //test.h int add(int a, int b); }}} {{{#!hs //test.c int add(int a, int b){ return (a + b); } }}} {{{#!hs //mylib.c #include "test.h" int testAdd(){ return add(2,3); } }}} Then I compile via : {{{#!hs gcc -shared -o libtest.so test.c gcc -fPIC -c mylib.c -o mylib.o gcc -shared -o libMy.so mylib.o }}} Then I have Main.hs with : {{{#!hs module Main where import Foreign.C.Types foreign import ccall "testAdd" c_testAdd :: CInt -> CInt -> IO (CInt) main = do result <- c_testAdd 3 4 print result }}} and I have the associated cabal file : {{{#!hs name: illustrate version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable illustrate main-is: Main.hs build-depends: base >=4.8 && <4.9 default-language: Haskell2010 extra-lib-dirs: ./ ghc-options: -ltest -lMy }}} Then upon running "cabal repl" I get the following error message (in ghc 7.10.1) : {{{#!hs *Main> main /home/linux/programs/ghc-7.10.1/lib/ghc-7.10.1/bin/ghc: symbol lookup error: ./libMy.so: undefined symbol: add }}} If I do "cabal run" I get : {{{#!hs Preprocessing executable 'illustrate' for illustrate-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/illustrate /illustrate-tmp/Main.o ) Linking dist/build/illustrate/illustrate ... Running illustrate... /home/linux/Downloads/illustrate/dist/build/illustrate/illustrate: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory }}} Note that in ghc 7.8.3, cabal 1.22.0.0 it works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 20:33:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 20:33:36 -0000 Subject: [GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall In-Reply-To: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> References: <045.5f1cfb88fc2e3dd9c933ec8683824602@haskell.org> Message-ID: <060.8465ae2c6d172c977b3b2f5d8f8262e9@haskell.org> #8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | https://gist.github.com/qnikst/324a66914b3aba878be5 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by qnikst): Looks like this issue still have happen in some weird situation, currently I have the same issue, in a file that uses constant in quasi-quoter, but only when I'm using haddock (ghc builds fine). Not sure that it will be easy to write a minimal example because this problem involves many parts (quasiquotes, foreing-interface, external library), but many it will give an ideas of what is happening. This issue is reproducible on 7.8 and 7.10. Should I fill a separate bug for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 20:39:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 20:39:40 -0000 Subject: [GHC] #10441: msys native python testsuite support doesn't work in some situations In-Reply-To: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> References: <045.e4f7bc692c0e65ad85c06fc026c6c89a@haskell.org> Message-ID: <060.2bc9373afb8752ddfa1642f0720c0c1e@haskell.org> #10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I partially understand what's going on. In commit 5258566ee5c89aa757b0cf1433169346319c018f I simplified the string formatting and program path quoting in the testsuite driver. One change is that the path of the GHC executable is now double quoted instead of single quoted. (This is done before it reaches the Python part of the testsuite driver, in `mk/test.mk`. I just noticed an unrelated bug here with empty program paths, which I'll fix shortly). This change is apparently not compatible with the escaping that `passThroughCmd` does. Before (good): {{{ #!python >> passThroughCmd(["timeout", "300", "cd . && 'inplace/ghc-stage2' -c foo"])[2] timeout "300" "cd . && 'inplace/ghc-stage2' -c foo" }}} After (bad): {{{ #!python >> passThroughCmd(['timeout', '300', 'cd . && "inplace/ghc-stage2" -c foo'])[2] timeout "300" "cd . && "inplace/ghc-stage2" -c foo" }}} If everything works after removing the function `passThroughCmd` introduced in 101c62e26286353dd3fac1ef54323529b64c9902, I suggest doing that. > # When running under native msys Python, any invocations of non-msys binaries, > # including timeout.exe, will have their arguments munged according to some > # heuristics Maybe the heuristics changed in a new version of msys, or the change from single quoting to double quoting somehow effects it?. Otherwise changing `'"%s"'` to `"'%s'"` might work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 21:05:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 21:05:49 -0000 Subject: [GHC] #10305: Windows validate failures In-Reply-To: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> References: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> Message-ID: <061.00364bcef1196ee8fadcc4b31ea19cf5@haskell.org> #10305: Windows validate failures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6694ccf9444baf565eb0f38f7808767616f23825/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6694ccf9444baf565eb0f38f7808767616f23825" testsuite: handle missing stats files gracefully (#10305) The following tests would result in framework failures when using a ghc build with HADDOCK_DOCS=NO in mk/build.mk or mk/validate.mk: * haddock.Cabal * haddock.base * haddock.compiler Test Plan: run make in tests/perf/haddock Differential Revision: https://phabricator.haskell.org/D899 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Sat May 23 21:08:02 2015 From: mechvel at botik.ru (Sergei Meshveliani) Date: Sun, 24 May 2015 01:08:02 +0400 Subject: overlapping instances in 7.10.1 Message-ID: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru> Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei From ghc-devs at haskell.org Sat May 23 21:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 21:26:54 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.0f436ce05b4e5cc0c8005dfe88148261@haskell.org> #8981: ghc-pkg complains about missing haddock interface files -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: ghc-pkg | Version: 7.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): See #10305 for an instance of this bug when running validate or a normal ghc build with `HADDOCK_DOCS=NO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 23 21:29:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 May 2015 21:29:23 -0000 Subject: [GHC] #10305: Windows validate failures In-Reply-To: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> References: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> Message-ID: <061.e3c62b296fec406be4ec92d192f4c5bc@haskell.org> #10305: Windows validate failures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8981 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8981 Comment: You are most likely setting `HADDOCK_DOCS=NO` in your `mk/validate.mk` file (on your Windows machine only, which is why you don't see these errors on Linux). That should normally be ok, but see below. > * Some unexpected failures. Let's ignore those for now, since they are probably all different Ok. These are the only problems that are Windows only in this ticket. > * Some Python traceback stuff; this must be a bug. It was. Should be fixed now. > * Tons of warnings about `haddock-interfaces` This is an instance of #8981. A workaround is to use `HADDOCK_DOCS=YES` (the default) in mk/build.mk or mk/validate.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 02:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 02:40:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM3ODcwOiBDb21waWxhdGlv4oCLbiBlcnJvcnMg?= =?utf-8?q?break_the_complexity_encapsulat=E2=80=8Bion_on_DSLs=2C?= =?utf-8?q?_impairs_success_in_industry?= In-Reply-To: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> References: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> Message-ID: <063.28190eb032c8a59581e7a6f800c86af9@haskell.org> #7870: Compilatio?n errors break the complexity encapsulat?ion on DSLs, impairs success in industry -------------------------------------+------------------------------------- Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: DSL, Resolution: | Error, Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 07:20:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 07:20:36 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.45ca62ea23cd5192d12ea5871cf7fb6c@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: flag Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9590 | Blocking: | Differential Revisions: Phab:D171 -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9590 Comment: Tbh, I wouldn't like seeing the `ghc-options: -is-prelude foobar` approach spread, as it would be a rather adhoc GHC-specific hack IMO, and also require `if impl(ghc >= ...)` guards if older GHCs are to be supported Moreover, I don't understand why the current implicit `Prelude` approach requires "having to import an alternative prelude everywhere", and how `-is-prelude` would help here. (I'd also like to point to comment:ticket:9590:20) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 15:07:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 15:07:54 -0000 Subject: [GHC] #10443: Regression in forall typechecking Message-ID: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following bug showed up when trying to install ghc-mod against the current ghc-7.10 branch Ths code below, from https://github.com/DanielG/ghc- mod/blob/b52c0a5d767282369f2748c5ec070b802ed8e23c/Language/Haskell/GhcMod/Monad/Types.hs#L346 {{{#!hs instance (MonadBaseControl IO m) => MonadBaseControl IO (GhcModT m) where type StM (GhcModT m) a = StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m) ) ) ) a liftBaseWith f = GhcModT . liftBaseWith $ \runInBase -> f $ runInBase . unGhcModT restoreM = GhcModT . restoreM {-# INLINE liftBaseWith #-} {-# INLINE restoreM #-} }}} Which compiles fine with GHC 7.10.1 now has the error {{{ Language/Haskell/GhcMod/Monad/Types.hs:346:13: Couldn't match expected type ?StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a1 -> IO (StM m (Either GhcModError (a1, GhcModState), GhcModLog))? with actual type ?forall a2. StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a2 -> IO (StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m)))) a2)? Relevant bindings include runInBase :: forall a. StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m))) a -> IO (StM (StateT GhcModState (ErrorT GhcModError (JournalT GhcModLog (ReaderT GhcModEnv m)))) a) (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:48) f :: RunInBase (GhcModT m) IO -> IO a (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:18) liftBaseWith :: (RunInBase (GhcModT m) IO -> IO a) -> GhcModT m a (bound at Language/Haskell/GhcMod/Monad/Types.hs:345:5) In the first argument of ?(.)?, namely ?runInBase? In the second argument of ?($)?, namely ?runInBase . unGhcModT? }}} A laborious git bisect tracked it down to {{{ 681d82c0d44f06f0b958b75778c30b0910df982b is the first bad commit commit 681d82c0d44f06f0b958b75778c30b0910df982b Author: Simon Peyton Jones Date: Tue Apr 7 14:45:04 2015 +0100 Look inside synonyms for foralls when unifying This fixes Trac #10194 (cherry picked from commit 553c5182156c5e4c15e3bd1c17c6d83a95a6c408) :040000 040000 1f0e62661ed1c48a9cbfab72ca3e38bb9e501412 ef6786fdb952d3446121b27b56f6103533d52356 M compiler :040000 040000 d607f1bff94578b0677df9cba01371dad6b26a32 ac715cec4fd8d43a53ecee132eae2b4c0c65e31a M testsuite }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 15:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 15:14:39 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.764f14c4c82b1b65cf936c09257c40a6@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: flag Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9590 | Blocking: | Differential Revisions: Phab:D171 -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, here's a different way how to replace the default `Prelude` with the current tooling that would IMO reduce the need for an `-is-prelude` option: https://github.com/hvr/base-noprelude The basic idea is to have `base` sans the `Prelude` module, and then you just need to provide the `Prelude` module either locally in the Package, or by importing some other package that provides the `Prelude` module. For instance, there's the `extended-prelude` package example: https://github.com/hvr/base-noprelude/tree/master/examples/extended- prelude which can be then used simply by setting `build-depends: base-noprelude, extended-prelude` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 15:21:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 15:21:42 -0000 Subject: [GHC] #10443: Regression in forall typechecking In-Reply-To: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> References: <044.7362b4be773be0b820eb3b3df909767a@haskell.org> Message-ID: <059.5142fc01711de82696292d97468d6633@haskell.org> #10443: Regression in forall typechecking -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by alanz): Oops, steps to show up the problem, once the relevant version of GHC is built {{{ git clone https://github.com/DanielG/ghc-mod.git cd ghc-mod git checkout b52c0a5d767282369f2748c5ec070b802ed8e23c cabal install }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 15:31:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 15:31:06 -0000 Subject: [GHC] #9709: Make restarts itself sometimes, and that's OK In-Reply-To: <047.7c0fc01059fc26172e59c2fa7057aac7@haskell.org> References: <047.7c0fc01059fc26172e59c2fa7057aac7@haskell.org> Message-ID: <062.e68fad83400e9030f5756f386fa4372d@haskell.org> #9709: Make restarts itself sometimes, and that's OK -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): I can reproduce this by running the following with recent HEAD (25d1a716395e349736994759d1fcbb3721f3ee9f): {{{ ./boot ./configure make touch -r inplace/bin/ghc-cabal -d '-1 day' compiler/stage1/package-data.mk make -j2 }}} Below are my notes. {{{ # Don't put stage=2 in your build.mk file. cd ghc-build # Make sure compiler/stage1/package-data.mk is out of date, so that # `inplace/stage1/ghc-cabal configure ...` is run, which updates # compiler/stage1/inplace-pkg-config, which *should* trigger `make` to update # compiler/stage1/inplace-pkg-config-munged. touch -r inplace/bin/ghc-cabal -d '-1 day' compiler/stage1/package-data.mk make -j2 # This fails with: # # "Make has restarted itself 2 times; is there a makefile bug? ..." # # Analysis: # For some reason, make *does* update inplace-pkg-config-munged before # restarting itself when running with `-j1`, but it *doesn't* when running # with `-j2`. # This can be seen more clearly when deleting the following line from the # toplevel ghc.mk: # # else ifeq "$(MAKE_RESTARTS)" "1" # # Make will fail with both `-j1` as with `-j2`, but in the former case # inplace-pkg-config-munged is updated (you'll see the sed command in the # output), whereas in the latter it isn't. Using `-j2 -d` does seem to work, # which is very confusing. # In build-package-data.mk, we have the following two (expanded) rules. # # compiler/stage1/package-data.mk : inplace/bin/ghc-cabal # # inplace/bin/ghc-cabal configure ... (which is effectively): # touch compiler/stage1/inplace-pkg-config # touch "$@" # # compiler/stage1/inplace-pkg-config : compiler/stage1/package-data.mk # # And in compiler/ghc.mk: # # compiler/stage1/inplace-pkg-config-munged: compiler/stage1/inplace-pkg- config # sed ... "$@" # # What seems to work as a fix is changing the rule for inplace-pkg-config to: # # compiler/stage1/inplace-pkg-config : compiler/stage1/package-data.mk ; # # Note the semicolon, which turns this into an empty recipe [1]. No recipe is # not the same as an empty recipe. I don't quite understand why this works # though, or how robust this fix is. # See also [2] for why the original rule might be flawed (it should have # failed for `-j1` as well). It doesn't follow best practice number 2 from # [3], from the GNU make maintainer's blog: # # "Every non-.PHONY rule *must* update a file with the exact name of its target." # # TODO: can we find all such flawed rules in the ghc build system? # (using some sort of makelint). # # References: # [1] https://www.gnu.org/software/make/manual/html_node/Empty- Recipes.html # [2] https://stackoverflow.com/questions/12724137/why-does-make-not- consider-a-target-without-recipe-out-of-date-when-updated-by-a # [3] http://make.mad-scientist.net/papers/rules-of-makefiles/ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 17:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 17:19:54 -0000 Subject: [GHC] #10410: make install installs haddck.t files In-Reply-To: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> References: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> Message-ID: <061.3d273edf5c38326f924fa304497c4d69@haskell.org> #10410: make install installs haddck.t files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:903 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:903 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 17:44:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 17:44:59 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken Message-ID: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ Prelude> lex "&) = mempty" [("&",") = mempty")] Prelude> lex "?) = mempty" [] }}} I traced this problem to Text.Read.Lex.lex -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 18:09:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 18:09:07 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.ce0afe6497e84b61b1a6a980b91e1a41@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mfdyck.google): I have a patch for this but I need Google to release it; asking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 18:23:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 18:23:13 -0000 Subject: [GHC] #9841: Touching a file that uses TH triggers TH recompilation flood In-Reply-To: <042.a8778786cec9a1cfbb06d527a298d097@haskell.org> References: <042.a8778786cec9a1cfbb06d527a298d097@haskell.org> Message-ID: <057.e4d6c957ccd8cb5600fac8e3ffc1170a@haskell.org> #9841: Touching a file that uses TH triggers TH recompilation flood -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #481, #7277 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * component: Build System => Driver -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 18:31:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 18:31:15 -0000 Subject: [GHC] #9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory) In-Reply-To: <048.b22670e5d522ad65bd728cccad384d67@haskell.org> References: <048.b22670e5d522ad65bd728cccad384d67@haskell.org> Message-ID: <063.56d656034b4f8dfdec190ae2d2c42113@haskell.org> #9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9651 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9651 Comment: This looks like a duplicate of #9651, which was fixed in commit 0899caab400e7a095528ea769a7e93a33717ae72: {{{ Author: Edward Z. Yang <> Date: Sat Dec 27 10:57:30 2014 -0500 Use directory-style database for bootstrapping database Summary: This allows GHC HEAD to be bootstrapped using 7.10. Signed-off-by: Edward Z. Yang <> Test Plan: validate Reviewers: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D589 GHC Trac Issues: #9652 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 18:52:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 18:52:09 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc In-Reply-To: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> References: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> Message-ID: <060.898f1048617fe41cb7a96ba613d4b9c1@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => low * status: patch => new * differential: Phab:D334 => Comment: >> austin says: >> In general I think we should actively move this to an autoconf check that then sets ghc-options appropriately, based on if the C compiler specified actually supports this flag or not. This will be much more robust in general, I think. > gintas says: > Makes sense. Probably more trouble than it's worth, that warning should get dropped from gcc eventually... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 23:39:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 23:39:02 -0000 Subject: [GHC] #3533: mac installer package deletes old version of ghc In-Reply-To: <068.c01b30dc01c8d35f26692e95513280f4@haskell.org> References: <068.c01b30dc01c8d35f26692e95513280f4@haskell.org> Message-ID: <083.9c17f1aa7ff10b9f551b3d5d588e880e@haskell.org> #3533: mac installer package deletes old version of ghc -------------------------------------+------------------------------------- Reporter: | Owner: malcolm.wallace@? | Status: closed Type: bug | Milestone: 7.12.1 Priority: lowest | Version: 6.10.4 Component: Build System | Keywords: Resolution: wontfix | Architecture: x86 Operating System: MacOS X | Test Case: Type of failure: Installing GHC | Blocking: failed | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: It seems that starting with 7.6 we don't offer any OS X installer package anymore [1], so it can't be broken either! Closing this 6 year old bug. [1] https://www.haskell.org/ghc/download_ghc_7_6_1#macosxintel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 24 23:51:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 May 2015 23:51:38 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.1302957bc13f819e7ef68044c8cab623@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: low => normal * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 02:16:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 02:16:45 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.a6bb8cec0f9bb1a02f65fc01b24dacf3@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Added a `static int count=0` variable that gets incremented each time the `schedule` function passes through the `ThreadRunGHC` case statement. I then added a printf: {{{ printf ("%d : %u %u\n", count, cap->no, (unsigned)cap->r.rCurrentTSO->id); }}} and running it with the `getChar` in `.ghci` I note that the last set of values printed by this statement before it segfaults is: {{{ 183 : 0 22 }}} So I run it again and attached GDB when the process is waiting for `getChar` and then set a breakpoint: {{{ (gdb) break rts/Schedule.c:490 if (count == 183 && cap->no == 0 && cap->r.rCurrentTSO->id == 22) }}} only to have the process crash in a completely different way: {{{ Program received signal SIGILL, Illegal instruction. 0xb2c56c7a in schedule (initialCapability=0xb2c96180 , task=0x10faf8) at rts/Schedule.c:491 (gdb) bt #0 0xb2c56c7a in schedule (initialCapability=0xb2c96180 , task=0x10faf8) at rts/Schedule.c:491 #1 0xb2c59040 in scheduleWaitThread (tso=0xb2707000, ret=0x0, pcap=0xbeffe944) at rts/Schedule.c:2408 #2 0xb2c47c98 in rts_evalLazyIO (cap=0xbeffe944, p=0xd2c30 , ret=0x0) at rts/RtsAPI.c:500 #3 0xb2c5a0fc in real_main () at rts/RtsMain.c:63 #4 0xb2c5a1d0 in hs_main (argc=3, argv=0xbeffeb04, main_closure=0xd2c30 , rts_config=...) at rts/RtsMain.c:114 #5 0x000cd2c6 in main () (gdb) dis 0xb2c56c7a warning: bad breakpoint number at or near '0xb2c56c7a' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 03:50:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 03:50:56 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize Message-ID: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 05:24:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 05:24:56 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.5f275f99bcd8e2399c2bf341dc1be8c0@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): This does not need `deriving Eq`. The following in `.ghci` is enough to trigger it: {{{ data X = Y let eqX = \ a b -> case a of { Y -> case b of { Y -> True }} eqX Y Y }}} but none of the other obvious nullary contructors like: {{{ True == True Nothing == Nothing }}} trigger it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 12:11:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 12:11:38 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.b4e205ff32703860fd8153983647353c@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Changes (by erdeszt): * status: new => patch * differential: => Phab:D902 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 12:20:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 12:20:23 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.38315f512d1c85a83c546cb056c8227c@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Comment (by erdeszt): I've added the name sleepBlock that's how it's refered in the codebase (although with slightly different signature, not sure if it matters). I also see that the version says 7.8.4 but I've made my fix on the latest master. Is it my responsibility to add it to the older branches or is it done automatically? (Sorry, first contribution and couldn't find relevant info in wiki) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 14:29:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 14:29:13 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.6a6da01ad4a0fdedef0289f4f6732dcf@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"326989ed06e6ad52d1cc2307be19d21b66b95813/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="326989ed06e6ad52d1cc2307be19d21b66b95813" Add missing name for FFI import (fixes #9950) Signed-off-by: erdeszt Reviewed By: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D902 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 14:33:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 14:33:19 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.9f7ed8328f5031f3f0f41c55f83d700a@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 Comment: In general we only work on master. Only important fixes are backported to the 7.10 (or latest release) branch by the release manager. You can read more about that here: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases The meaning of the version field is explained here : https://ghc.haskell.org/trac/ghc/wiki/ReportABug#Whattoputinabugreport Thanks for the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 14:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 14:41:40 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.56048b036b2950d1a49ce48110bd3990@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Comment (by erdeszt): Thank you for the links, will read through through them! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 16:02:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 16:02:26 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.fe8ad13613084877b4901b7e4c0ccaef@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by carter): @erikd, your register snapshot doesnt make sense, it names x86_64 registers, namely XMM*, YMM* , and ZMM* families, but your code is on ARM right? Or am I misreading the dump? Replying to [comment:15 erikd]: > Using the gdb macros on the wiki I can retrieve the following info after the segfault: > > {{{ > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb14ff460 (LWP 7214)] > 0xb88d09d4 in ?? () > (gdb) bt > #0 0xb88d09d4 in ?? () > #1 0x70000000 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) pregs > $1 = {rR1 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > ,rR2 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR3 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR4 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR5 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR6 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR7 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR8 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR9 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rR10 = {w = 0, a = 0x0, c = 0, f = 0, i = 0, p = 0x0} > , rF1 = 0, rF2 = 0, rF3 = 0, rF4 = 0, rF5 = 0, rF6 = 0 > , rD1 = 0, rD2 = 0, rD3 = 0, rD4 = 0, rD5 = 0, rD6 = 0 > , rXMM1 = {h = 0, l = 0} > , rXMM2 = {h = 0, l = 0} > , rXMM3 = {h = 0, l = 0} > , rXMM4 = {h = 0, l = 0} > , rXMM5 = {h = 0, l = 0} > , rXMM6 = {h = 0, l = 0} > , rYMM1 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rYMM2 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rYMM3 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rYMM4 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rYMM5 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rYMM6 = {h = {h = 0, l = 0}, l = {h = 0, l = 0}} > , rZMM1 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rZMM2 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rZMM3 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rZMM4 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rZMM5 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rZMM6 = {h = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}, l = {h = {h = 0, l = 0}, l = {h = 0, l = 0}}} > , rL1 = 0, rSp = 0x0, rSpLim = 0x0, rHp = 0x0, rHpLim = 0xb08fbfff > , rCCCS = 0x0, rCurrentTSO = 0xb09cc8a4, rNursery = 0x109078 > , rCurrentNursery = 0xb0801f60, rCurrentAlloc = 0xb0901980, rHpAlloc = 0, rRet = 3} > (gdb) ptso > $2 = {header = {info = 0xb2bf43c0 }, _link = 0xb2c146d8 > , global_link = 0xb2c146d8 > , stackobj = 0xb09cc4f4, what_next = 1, why_blocked = 0, flags = 0 > , block_info = {closure = 0xb2c146d8 > , prev = 0xb2c146d8 > , bh = 0xb2c146d8 > , throwto = 0xb2c146d8 > , wakeup = 0xb2c146d8 > , fd = -1295956264 > } > , id = 22, saved_errno = 0, dirty = 1 > , bound = 0x0, cap = 0xb2c16180 > , trec = 0xb2c146d0 > , blocked_exceptions = 0xb2c146d8 > , bq = 0xb2c146d8 > , alloc_limit = 2592, tot_stack_size = 232 > } > (gdb) info registers > r0 0xb6f73018 3069653016 > r1 0xb2bf434c 2998879052 > r2 0x1 1 > r3 0xb09cc7c6 2963064774 > r4 0xb2c16190 2999017872 > r5 0xb09cc81c 2963064860 > r6 0xb08fbbf4 2962209780 > r7 0xb09cc938 2963065144 > r8 0xb14fefa0 2974805920 > r9 0x0 0 > r10 0xb2bf4160 2998878560 > r11 0xb09cc558 2963064152 > r12 0xb2c15b8c 2999016332 > sp 0xb14fcd68 0xb14fcd68 > lr 0x70000000 1879048192 > pc 0xb88d09d4 0xb88d09d4 > cpsr 0x400f0010 1074724880 > > }}} > > The `pc` register definitetly does contain a bad value, but there's no good explanation of how it got there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 16:21:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 16:21:32 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.412e6b02fc1ebe10b185dee5e9c9e837@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by bgamari): @carter, I was perplexed by this at first as well but if you look at the `info registers` output you'll see that GDB is indeed targetting the correct architecture. YMM and friends are only mentioned by the output of `pregs` (source here, https://ghc.haskell.org/trac/ghc/attachment/wiki/Debugging/CompiledCode/.gdbinit) which just prints the current thread's `StgRegTable` and indeed has fields of these names regardless of the architecture.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 17:33:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 17:33:40 -0000 Subject: [GHC] #9430: implement more arithmetic operations natively in the LLVM backend In-Reply-To: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> References: <047.5faa8daf1edcacef61c9001ac8b43152@haskell.org> Message-ID: <062.a904ee10ec6fae96c119a8f673d086d5@haskell.org> #9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by michalt): * owner: => michalt Comment: This looks like a nice way to learn more about LLVM backend, so I've started working on adding support for: `MO_Add2` and `MO_{Add,Sub}IntC`. I hope to send something out within the next few days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 18:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 18:50:42 -0000 Subject: [GHC] #10446: Fix error message when variables in a static form are not in scope Message-ID: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> #10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple StaticPointers | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If an identifier is out-of-scope but inside a static form ({{{static f}}}) then GHC says expression not closed, when really it should just say identifier out of scope. {{{ t.hs:6:5: error: Only identifiers of top-level bindings can appear in the body of the static form: static f but the following identifiers were found instead: f }}} We just want: {{{ t.hs:6:12: error: Not in scope: ?f? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 19:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 19:02:20 -0000 Subject: [GHC] #10446: Fix error message when variables in a static form are not in scope In-Reply-To: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> References: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> Message-ID: <071.2f16cb878ca7c9fe79f42c3269e650c0@haskell.org> #10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | StaticPointers Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab: D906 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab: D906 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 19:03:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 19:03:16 -0000 Subject: [GHC] #10446: Fix error message when variables in a static form are not in scope In-Reply-To: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> References: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> Message-ID: <071.603d6c56a58d333d69d4e511c1c9d8a0@haskell.org> #10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | StaticPointers Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D906 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: Phab: D906 => Phab:D906 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 20:38:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 20:38:47 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.635d41948957a87c68b12b4757a533ca@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): By hacking `mk/config.mk.in` I was able to compile with `DYNAMIC_GHC_PROGRAMS` set to `NO` and create a `ghc-stage2` compiler that dynamically links only to the C libraries. It also crashes just in a different way. Regardless of whether a `.ghci` file exists, `ghc-stage2 --interactive` crashes with `Illegal instruction` as soon as it is run and before it even diplays a prompt: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150523: http://www.haskell.org/ghc/ :? for help Illegal instruction }}} Checking the settings file, I find that the `ld.gold` linker *is* being used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 20:48:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 20:48:50 -0000 Subject: [GHC] #10092: lex doesn't handle binary literals In-Reply-To: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> References: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> Message-ID: <065.0256f47700299b206cf81bb291f36d76@haskell.org> #10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | BinaryLiterals report-impact Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9224 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm OK with that, I just wanted to confirm that {{{lex}}} was in fact meant to adhere to a portable implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 20:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 20:55:49 -0000 Subject: [GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi In-Reply-To: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> References: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> Message-ID: <065.d9f69023987ea97a6a787d9ab20db0f8@haskell.org> #10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9830 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9830 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 21:21:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 21:21:07 -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.6698d45f576f10d0dd6c54180422a013@haskell.org> #7521: Simplifier ticks exhausted when compiling Accelerate example. -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Should the subject/title, "Simplifier ticks exhausted when compiling Accelerate example" be changed since it is no longer accurate? Given that should the priority be changed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 21:25:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 21:25:40 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText In-Reply-To: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> References: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> Message-ID: <059.445f197f1ccd56260db5751652bb577a@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D907 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D907 * milestone: 7.12.1 => 7.10.2 Comment: I have set the milestone to 7.10.2, as this is the last item blocking a full hackage round trip, resulting in 40 or so failing files out of around 50k. It does require a tiny change to Haddock, but is basically just adding `SourceText` fields to the last places they are required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 23:23:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 23:23:37 -0000 Subject: [GHC] #10092: lex doesn't handle binary literals In-Reply-To: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> References: <050.36d0be4204ee95d5f9c78410dc1eb92c@haskell.org> Message-ID: <065.601ad549e8a45d03c1a7c437d92b8af9@haskell.org> #10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | BinaryLiterals report-impact Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9224 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 23:31:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 23:31:40 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable In-Reply-To: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> References: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> Message-ID: <065.a9887a1b8cfe594ff53b442cd86ef470@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'd be okay with combining kind and type arguments in {{{typeRepArgs}}}, especially since {{{template-haskell}}} does this already. I don't have a particular use case to cite, just the desire for parity with the other fields of {{{TypeRep}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 25 23:36:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 May 2015 23:36:46 -0000 Subject: [GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi In-Reply-To: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> References: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> Message-ID: <065.84553f9209893c97a53c3392978d90e1@haskell.org> #10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9830 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure if this is related, but when I tried declaring the above data type with {{{infixr 5 :@:}}} first, GHCi fails to parse it: {{{ $ ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ?> infixr 5 :@:; data Infix a b = a :@: b deriving Show :2:1: parse error on input ?infixr? }}} It's possible that this bug wouldn't manifest itself if the {{{infixr}}} declaration appeared first, but GHCi won't allow this in the first place, so it's impossible to tell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 00:08:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 00:08:45 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.7d0d8ee24bc18471548081e0175f5af7@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): With the `DYNAMIC_GHC_PROGRAMS = NO` version of `ghc-stage2` I can actually run it under GDB directly, instead of running it in one terminal and attaching GDB to it from another terminal. However, if I try to set a breakpoint suddenly GDB and `ghc-stage2`'s terminal manipulation start fighting each other again. The above problem means I'm back to attaching GDB to `ghc-stage2` from a separate terminal, but I can't do it with a `getChar` in the `.gchi` file because the statically linked `ghc-stage2` is crashing before it loads the `.ghci` file. Instead, I have hacked `ghc/Main.hs` as follows: {{{ main :: IO () main = do + args <- getArgs + if "--interactive" `elem` args + then do + putStr "Continue ... " + hFlush stdout + _ <- getChar + putStrLn "done" + else return () initGCStatistics -- See Note [-Bsymbolic and hooks] hSetBuffering stdout LineBuffering hSetBuffering stderr LineBuffering }}} This does allow me to attach GDB, but then I'm stuck with the same problem as before, attaching GDB changes the state of the program to an extent where I can't catch the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 00:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 00:12:48 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type Message-ID: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8678 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, the {{{-XDeriveFoldable}}} extension will reject any derived {{{Foldable}}} instance for a data type where the last argument of the type constructor is constrained. For example, using this data type from [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1425 TcDeriv.hs] as inspiration: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) deriving instance Foldable (T a) }}} Compiling {{{DeriveFoldableRejected.hs}}} with GHC 7.10 will currently fail: {{{ DeriveFoldableRejected.hs:9:1: Can't make a derived instance of ?Foldable (T a)?: Constructor ?T4? must be truly polymorphic in the last argument of the data type In the stand-alone deriving instance for ?Foldable (T a)? Failed, modules loaded: none. }}} I don't think this restriction needs to apply to {{{Foldable}}} instances. Unlike {{{Functor}}} and {{{Traversable}}} instances, which require the last argument to be truly universal, {{{Foldable}}} instances can get away without this. To demonstrate, here's a slightly modified {{{T}}} data type, without the constraints: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module DeriveFoldableLegal where data T a b where T45 :: b -> T a b T6 :: T a b deriving instance Foldable (T a) }}} The output of {{{-ddump-deriv}}} is: {{{ Derived instances: instance Data.Foldable.Foldable (DeriveFoldableRejected.T a_aDc) where Data.Foldable.foldr f_aDd z_aDe (DeriveFoldableRejected.T45 a1_aDf) = f_aDd a1_aDf z_aDe Data.Foldable.foldr f_aDg z_aDh DeriveFoldableRejected.T6 = z_aDh Data.Foldable.foldMap f_aDi (DeriveFoldableRejected.T45 a1_aDj) = f_aDi a1_aDj Data.Foldable.foldMap f_aDk DeriveFoldableRejected.T6 = GHC.Base.mempty }}} Copying this back into {{{DeriveFoldableRejected.hs}}} (after some cleanup): {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) instance Foldable (T a) where foldr f z (T4 a) = f a z foldr f z (T5 a) = f a z foldr f z T6 = z foldMap f (T4 a) = f a foldMap f (T5 a) = f a foldMap f T6 = mempty }}} reveals that it will compile correctly with the generated code. Therefore, it seems like the check for universality in the last type argument shouldn't be used in {{{-XDeriveFoldable}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 00:13:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 00:13:44 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.560ad0853a22cc2f252e5601882c6f3d@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Currently, the {{{-XDeriveFoldable}}} extension will reject any derived > {{{Foldable}}} instance for a data type where the last argument of the > type constructor is constrained. For example, using this data type from > [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1425 > TcDeriv.hs] as inspiration: > > {{{#!hs > {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} > module DeriveFoldableRejected where > > data T a b where > T4 :: Ord b => b -> T a b > T5 :: b -> T b b > T6 :: T a (b,b) > > deriving instance Foldable (T a) > }}} > > Compiling {{{DeriveFoldableRejected.hs}}} with GHC 7.10 will currently > fail: > > {{{ > DeriveFoldableRejected.hs:9:1: > Can't make a derived instance of ?Foldable (T a)?: > Constructor ?T4? must be truly polymorphic in the last argument of > the data type > In the stand-alone deriving instance for ?Foldable (T a)? > Failed, modules loaded: none. > }}} > > I don't think this restriction needs to apply to {{{Foldable}}} > instances. Unlike {{{Functor}}} and {{{Traversable}}} instances, which > require the last argument to be truly universal, {{{Foldable}}} instances > can get away without this. To demonstrate, here's a slightly modified > {{{T}}} data type, without the constraints: > > {{{#!hs > {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} > {-# OPTIONS_GHC -ddump-deriv #-} > module DeriveFoldableLegal where > > data T a b where > T45 :: b -> T a b > T6 :: T a b > > deriving instance Foldable (T a) > }}} > > The output of {{{-ddump-deriv}}} is: > > {{{ > Derived instances: > instance Data.Foldable.Foldable > (DeriveFoldableRejected.T a_aDc) where > Data.Foldable.foldr f_aDd z_aDe (DeriveFoldableRejected.T45 a1_aDf) > = f_aDd a1_aDf z_aDe > Data.Foldable.foldr f_aDg z_aDh DeriveFoldableRejected.T6 = z_aDh > Data.Foldable.foldMap f_aDi (DeriveFoldableRejected.T45 a1_aDj) > = f_aDi a1_aDj > Data.Foldable.foldMap f_aDk DeriveFoldableRejected.T6 > = GHC.Base.mempty > }}} > > Copying this back into {{{DeriveFoldableRejected.hs}}} (after some > cleanup): > > {{{#!hs > {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} > module DeriveFoldableRejected where > > data T a b where > T4 :: Ord b => b -> T a b > T5 :: b -> T b b > T6 :: T a (b,b) > > instance Foldable (T a) where > foldr f z (T4 a) = f a z > foldr f z (T5 a) = f a z > foldr f z T6 = z > > foldMap f (T4 a) = f a > foldMap f (T5 a) = f a > foldMap f T6 = mempty > }}} > > reveals that it will compile correctly with the generated code. > Therefore, it seems like the check for universality in the last type > argument shouldn't be used in {{{-XDeriveFoldable}}}. New description: Currently, the {{{-XDeriveFoldable}}} extension will reject any derived {{{Foldable}}} instance for a data type where the last argument of the type constructor is constrained. For example, using this data type from [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1425 TcDeriv.hs] as inspiration: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) deriving instance Foldable (T a) }}} Compiling {{{DeriveFoldableRejected.hs}}} with GHC 7.10 will currently fail: {{{ DeriveFoldableRejected.hs:9:1: Can't make a derived instance of ?Foldable (T a)?: Constructor ?T4? must be truly polymorphic in the last argument of the data type In the stand-alone deriving instance for ?Foldable (T a)? Failed, modules loaded: none. }}} I don't think this restriction needs to apply to {{{Foldable}}} instances. Unlike {{{Functor}}} and {{{Traversable}}} instances, which require the last argument to be truly universal, {{{Foldable}}} instances can get away without this. To demonstrate, here's a slightly modified {{{T}}} data type, without the constraints: {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module DeriveFoldableLegal where data T a b where T45 :: b -> T a b T6 :: T a b deriving instance Foldable (T a) }}} The output of {{{-ddump-deriv}}} is: {{{ Derived instances: instance Data.Foldable.Foldable (DeriveFoldableLegal.T a_aDc) where Data.Foldable.foldr f_aDd z_aDe (DeriveFoldableLegal.T45 a1_aDf) = f_aDd a1_aDf z_aDe Data.Foldable.foldr f_aDg z_aDh DeriveFoldableLegal.T6 = z_aDh Data.Foldable.foldMap f_aDi (DeriveFoldableLegal.T45 a1_aDj) = f_aDi a1_aDj Data.Foldable.foldMap f_aDk DeriveFoldableLegal.T6 = GHC.Base.mempty }}} Copying this back into {{{DeriveFoldableRejected.hs}}} (after some cleanup): {{{#!hs {-# LANGUAGE DeriveFoldable, GADTs, StandaloneDeriving #-} module DeriveFoldableRejected where data T a b where T4 :: Ord b => b -> T a b T5 :: b -> T b b T6 :: T a (b,b) instance Foldable (T a) where foldr f z (T4 a) = f a z foldr f z (T5 a) = f a z foldr f z T6 = z foldMap f (T4 a) = f a foldMap f (T5 a) = f a foldMap f T6 = mempty }}} reveals that it will compile correctly with the generated code. Therefore, it seems like the check for universality in the last type argument shouldn't be used in {{{-XDeriveFoldable}}}. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 02:03:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 02:03:27 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.180c636131c079f0f2cf202185a423f0@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => merge * milestone: 7.12.1 => 7.10.2 Comment: We can totally merge this one to STABLE, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 02:05:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 02:05:36 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example In-Reply-To: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> References: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> Message-ID: <057.7c7bc9813186ae8b3fe12c860a2b5e01@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: erdeszt Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D902 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 02:05:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 02:05:46 -0000 Subject: [GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure In-Reply-To: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> References: <051.c1ff4a433273f857fbe1c94f26326a30@haskell.org> Message-ID: <066.d18ba688c15c871dde7dd783dea20e24@haskell.org> #10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 02:06:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 02:06:13 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.c973e16730c21a3fbd6772fba07fd399@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect | Blocking: warning at compile-time | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tonyday567): I found a similar bug with this same command here: https://github.com/mikeizbicki/subhask/commit/c98d2b5f1184153820867d83e4fba44118b97bc2 Error: {{{ : ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: subhazuAF2UqVq5DNs9kS0u9qf2pe_SubHaskziTemplateHaskellziMutable_mkMutable_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} As far as I can tell, it doesn't involve Lens. ghc --interactive and cabal build both work fine, so the bug is isolated to the -fno-code flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 02:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 02:51:56 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.2925a9ff65cd8829c601ad9edf1909d3@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): We've run into what seems to be the same issue. We've isolated a test case here: https://gist.github.com/j-e-k/bf8c5f027178ee20ac94 Could we get this fixed in `7.10.2`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 03:31:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 03:31:33 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.7c10ab44d685778b386dcda522dbb3bb@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): By hacking `configure.ac` I managed to build GHC with `-fsanitize=address` passed to GCC. Absolutely, positively, 100% certain that something is wrong: {{{ $ inplace/bin/ghc-stage2 --interactive ASAN:SIGSEGV ================================================================= ==7051==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000 (pc 0x00000000 sp 0xbeffe5f0 bp 0x37dffd15 T0) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ??:0 ?? }}} `ghc-stage2` compiled with AddressSanitizer on `x86_64/linux` does not do the above. Unfortunately, while AddressSanitizer has found a problem, it doesn't provide any new information. I suspect it doesn't know enough about GHC's run time and calling conventions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 03:39:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 03:39:35 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.8ffbd6b74648d711eb7df7b121ef9e9f@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): This is interesting. with GHC compiled with AddressSanitizer, it no longer needs `--interactive` to bring on a crash. In fact just running `inplace/bin/ghc-stage2` on the command line with no arguments crashes with a SIGSEGV. In GDB: {{{ (gdb) r Starting program: /home/erikd/Git/ghc-upstream/inplace/lib/bin/ghc-stage2 -B/home/erikd/Git/ghc-upstream/inplace/lib [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0xb6b2db4c in pthread_cond_init () from /usr/lib/arm-linux-gnueabihf/ libasan.so.1 #2 0xb1e1407c in newTask (worker=rtsFalse) at rts/Task.c:218 #3 0xb1e14702 in allocTask () at rts/Task.c:128 #4 newBoundTask () at rts/Task.c:304 #5 0xb1df6970 in rts_lock () at rts/RtsAPI.c:556 #6 0xb1e40398 in ioManagerStart () at rts/posix/Signals.c:218 #7 0xb1dec428 in hs_init_ghc (argc=argc at entry=0xbeffe87c, argv=argv at entry= 0xbeffe878, rts_config=...) at rts/RtsStartup.c:263 #8 0xb1e14fb2 in hs_main (argc=-1310605083, argv=0xd88e1 , main_closure=0xdeb34 , rts_config=...) at rts/RtsMain.c:51 #9 0x000d8b3a in main () }}} Hopefully this isn't a red herring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 04:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 04:51:05 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6ccff7d32b73666743393ec74dfe5d93@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): I smell a rat, or maybe its a red herring. Seem to be getting SIGSEGV inside the call to `pthread_cond_init`. A bit of googling tells me that AddressSanitizer intercepts calls to `pthread_cond_init` and can get it wrong eg : https://code.google.com/p/address- sanitizer/issues/detail?id=297 . Sure enough, trivial C program: {{{ #include #include int main (void) { pthread_cond_t cond; pthread_cond_init(&cond, NULL); return 0; } }}} Works correctly when compiled and run (even under Valgrind) as: {{{ gcc -Wall cond_init.c -o cond_init && valgrind ./cond_init }}} but crashes with a SIGSEGV when compiled and run as: {{{ gcc -Wall -fsanitize=address cond_init.c -o cond_init && ./cond_init }}} Reported this as a bug in Debian's gcc : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=786850 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 05:04:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 05:04:50 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.74b0c0d6d4dad9174b0abe0ba2ca7d47@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 08:05:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 08:05:02 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.f03cefd22803b9448ed3fe5fa3cb1113@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: I think we can consider this particular task/ticket accomplished (as it made it into milestone:7.10.1) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 12:17:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 12:17:33 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.ba58df5f13b8e6b21f87c46e253ac507@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Did {{{Bifoldable}}} and {{{Bitraversable}}} (from the original proposal) not make it in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 16:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 16:16:13 -0000 Subject: [GHC] #10446: Fix error message when variables in a static form are not in scope In-Reply-To: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> References: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> Message-ID: <071.8f34c04023d2e6d312a25203fbbf5cca@haskell.org> #10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | StaticPointers Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D906 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"71d1f01db94dda5b8c2c367fba8cc7b115b06e95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="71d1f01db94dda5b8c2c367fba8cc7b115b06e95" Omit the static form error for variables not in scope. Summary: Fixes T10446. The following program > g = static f now produces only: > ...: error > Not in scope: 'f' Before it would also produce a complaint about 'f' not being a top-level identifier. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: bgamari, thomie, mboes Differential Revision: https://phabricator.haskell.org/D906 GHC Trac Issues: #10446 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 16:34:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 16:34:48 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal (1/3) (was: Implement "Add bifunctor related classes to base"-Proposal) In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.87b9b7ed4df72ef99bd3bc7b6cd8f524@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal (1/3) -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Comment (by hvr): There wasn't enough time to get the other two classes into shape for milestone:7.10.1, they'll get their own Trac ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 16:42:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 16:42:09 -0000 Subject: [GHC] #8122: make binary-dist broken on OS X in HEAD In-Reply-To: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> References: <047.e3f39dff89338f1ef14e78b10c690e19@haskell.org> Message-ID: <062.dfd7125d6695bb1ca2f07a659ef51d3a@haskell.org> #8122: make binary-dist broken on OS X in HEAD -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:5 edsko]: > It seems `$$($1_$2_PROG_INPLACE)` is explicitly only set when `BINDIST` is not equal to `YES` (lines 187, 200). But then how could this work for anyone? Replying to [comment:8 darchon]: > `make binary-dist` also started failing for me; I don't know why it worked earlier... For posterity, this got probably broken in commit c6a05a72d237cba0f17ea202f7c38ca0ac54aeb7: {{{ Author: Ian Lynagh < Date: Thu May 16 12:58:42 2013 +0100 Make dynamic GHC no Windows installable too We need different paths in the wrapper, as teh installed tree is a different shape to the build tree. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 17:25:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 17:25:16 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal Message-ID: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #9682 Test Case: | Blocking: | Differential Revisions: Phab:D336 | -------------------------------------+------------------------------------- Cloned from #9682: ---- See [http://www.haskell.org/pipermail/libraries/2014-April/022844.html original libraries@ proposal] for more details -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 17:26:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 17:26:57 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal (1/3) In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.97827e7bffd04c5c58b3b66e25eaac5f@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal (1/3) -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10448 | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Changes (by hvr): * related: => #10448 Comment: For the rest of this task see #10448 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 18:23:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 18:23:49 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText In-Reply-To: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> References: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> Message-ID: <059.44d22aed95d5f4fc3c8b15c74ade532a@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D907 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 21:14:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 21:14:32 -0000 Subject: [GHC] #9584: Interface file errors (Iface type variable out of scope: k) In-Reply-To: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> References: <050.e5963e681d716a12ba2c5dc2547d753a@haskell.org> Message-ID: <065.28c8a0cbbbc0f621baa41b553a041f88@haskell.org> #9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9263 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: OK good! I'll close as won't-fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 21:48:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 21:48:55 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler Message-ID: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------------------+---------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- Ever since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that out-of-tree tests will not run on MinGW anymore. Note that I am using MinGW tools with a native Windows build of Python, which is the main cause of the problem. The apparent error is something along the lines of "cannot eval an empty string": {{{ Traceback (most recent call last): File "testsuite/driver/runtests.py", line 196, in get_compiler_info() File "", line 166, in get_compiler_info File "", line 0 ^ SyntaxError: unexpected EOF while parsing }}} But this error is quite misleading. What really happened was that it tried to run GHC with the `--info` argument but failed silently and returned an empty string. If you apply D908, it becomes a lot more obvious: Python is failing to run `/c/programs/ghc/bin/ghc --info` because `/c/programs/ghc/bin/ghc` "does not exist" as Python does not understand MinGW-style paths. The funny thing is that it worked just fine before 525856, so you have to wonder why quoting the paths caused this. It turns out that MinGW does some magic behind the scenes, automagically converting MinGW-style paths into ordinary Python paths when a native Windows program is invoked. In particular, it means running this in MinGW shell {{{ python run-tests.py -e 'config.compiler=/c/programs/ghc/ghc' }}} will actually invoke Python with `config.compiler=C:/programs/ghc/ghc`. However, if it's explicitly quoted like this: {{{ python run-tests.py -e 'config.compiler="/c/programs/ghc/ghc"' }}} the magic doesn't work anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 21:58:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 21:58:11 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.4b0d1c6d25a09b90a370f974db6b107b@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Changes (by thomie): * related: => #10441 Comment: I guess this works as well? {{{ python run-tests.py -e "config.compiler='/c/programs/ghc/ghc'" }}} Can we try to not rely on this magic? See also #10441. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 22:09:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 22:09:56 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.32a1f8454dce3fffa05cf5a036e983cb@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Comment (by Rufflewind): Oops, what I said wasn't quite correct. The problem is actually that the quotes are ''escaped'': {{{ python run-tests.py -e 'config.compiler="\"/c/programs/ghc/ghc\""' }}} MinGW has no problem with single or double quotes. It's the ''escaped'' double quotes that cause problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 22:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 22:12:54 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.652e3dda37fa047cc3094ebe45b72676@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Description changed by Rufflewind: Old description: > Ever since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that > out-of-tree tests will not run on MinGW anymore. Note that I am using > MinGW tools with a native Windows build of Python, which is the main > cause of the problem. > > The apparent error is something along the lines of "cannot eval an empty > string": > > {{{ > Traceback (most recent call last): > File "testsuite/driver/runtests.py", line 196, in > get_compiler_info() > File "", line 166, in get_compiler_info > File "", line 0 > ^ > SyntaxError: unexpected EOF while parsing > }}} > > But this error is quite misleading. What really happened was that it > tried to run GHC with the `--info` argument but failed silently and > returned an empty string. If you apply D908, it becomes a lot more > obvious: Python is failing to run `/c/programs/ghc/bin/ghc --info` > because `/c/programs/ghc/bin/ghc` "does not exist" as Python does not > understand MinGW-style paths. > > The funny thing is that it worked just fine before 525856, so you have to > wonder why quoting the paths caused this. It turns out that MinGW does > some magic behind the scenes, automagically converting MinGW-style paths > into ordinary Python paths when a native Windows program is invoked. In > particular, it means running this in MinGW shell > > {{{ > python run-tests.py -e 'config.compiler=/c/programs/ghc/ghc' > }}} > > will actually invoke Python with `config.compiler=C:/programs/ghc/ghc`. > However, if it's explicitly quoted like this: > > {{{ > python run-tests.py -e 'config.compiler="/c/programs/ghc/ghc"' > }}} > > the magic doesn't work anymore. New description: Ever since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that out-of-tree tests will not run on MinGW anymore. Note that I am using MinGW tools with a native Windows build of Python, which is the main cause of the problem. The apparent error is something along the lines of "cannot eval an empty string": {{{ Traceback (most recent call last): File "testsuite/driver/runtests.py", line 196, in get_compiler_info() File "", line 166, in get_compiler_info File "", line 0 ^ SyntaxError: unexpected EOF while parsing }}} But this error is quite misleading. What really happened was that it tried to run GHC with the `--info` argument but failed silently and returned an empty string. If you apply D908, it becomes a lot more obvious: Python is failing to run `/c/programs/ghc/bin/ghc --info` because `/c/programs/ghc/bin/ghc` "does not exist" as Python does not understand MinGW-style paths. The funny thing is that it worked just fine before 525856, so you have to wonder why quoting the paths caused this. It turns out that MinGW does some magic behind the scenes, automagically converting MinGW-style paths into ordinary Python paths when a native Windows program is invoked. In particular, it means running this in MinGW shell {{{ python run-tests.py -e 'config.compiler=/c/programs/ghc/ghc' }}} will actually invoke Python with `config.compiler=C:/programs/ghc/ghc`. However, if it's explicitly quoted (''edit:'' and also escaped with backslashes) like this {{{ python run-tests.py -e 'config.compiler="\"/c/programs/ghc/ghc\""' }}} the magic doesn't work anymore. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 22:16:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 22:16:03 -0000 Subject: [GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) In-Reply-To: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> References: <044.8b5ce9f8e233bb071d820a2c5b8037cb@haskell.org> Message-ID: <059.a2d241c39da54e0df74efd4b9bee3ff7@haskell.org> #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'd love it to be fixed in 7.10.2, but first someone needs to volunteer to look into what is wrong, and hopefully find out how to fix it. Is it a bug in a library? In the RTS? In the compiler? Help needed! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 22:25:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 22:25:06 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.f25bc607dad8916f4d340dbbdc0ba8d2@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) Comment: Copying the Core Libraries Committee. What conditions ''are'' ok? For example, is this OK? {{{ data T a where MkT :: (a~Int) => a -> T a }}} or this (which is equivalent) {{{ data T a where MkT :: Int -> T Int }}} I think that the 'deriving' code for `Functor`, `Foldable` etc behaves specially when it comes across the universally-quantified type variable (`a` above), so it might get confused if it was `Int` and not `a`. Disabling the test is easy: the question is whether that's the right thing to do. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 26 23:14:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 May 2015 23:14:31 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.03a27b0d320aab1498b49abc0c17e732@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Comment (by thomie): But escaped single quotes are still ok? That's what was used before 525856. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 00:25:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 00:25:28 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.b242a859a0b35fb8e08b8d81fb5ac85d@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be a bit more explicit, {{{TcDeriv}}} specifies [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1331 these rules] for {{{DeriveFunctor}}}, {{{DeriveFoldable}}}, and {{{DeriveTraversable}}}: {{{ -- OK for Functor/Foldable/Traversable class -- Currently: (a) at least one argument -- (b) don't use argument contravariantly -- (c) don't use argument in the wrong place, e.g. data T a = T (X a a) -- (d) optionally: don't use function types -- (e) no "stupid context" on data type }}} These conditions are OK. I propose that [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcDeriv.hs#l1425 these additional rules] from {{{TcDeriv}}} only be used for {{{DeriveFunctor}}} and {{{DeriveTraversable}}}, not for {{{DeriveFoldable}}}: {{{ Note [Check that the type variable is truly universal] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For Functor, Foldable, Traversable, we must check that the *last argument* of the type constructor is used truly universally quantified. Example data T a b where T1 :: a -> b -> T a b -- Fine! Vanilla H-98 T2 :: b -> c -> T a b -- Fine! Existential c, but we can still map over 'b' T3 :: b -> T Int b -- Fine! Constraint 'a', but 'b' is still polymorphic T4 :: Ord b => b -> T a b -- No! 'b' is constrained T5 :: b -> T b b -- No! 'b' is constrained T6 :: T a (b,b) -- No! 'b' is constrained Notice that only the first of these constructors is vanilla H-98. We only need to take care about the last argument (b in this case). See Trac #8678. Eg. for T1-T3 we can write fmap f (T1 a b) = T1 a (f b) fmap f (T2 b c) = T2 (f b) c fmap f (T3 x) = T3 (f x) }}} These rules must hold for {{{Functor}}} and {{{Traversable}}} instances because the type signatures of {{{fmap :: Functor t => (a -> b) -> t a -> t b}}} and {{{traverse :: (Applicative f, Traversable t) => (a -> f b) -> t a -> f (t b)}}} require that the last type argument be truly polymorphic, since it must be instantiated with two arbitrary types, {{{t a}}} and {{{t b}}}. As evidence, if you try to make a {{{Functor T}}} instance using what {{{DeriveFunctor}}} would (hypothetically) generate: {{{#!hs {-# LANGUAGE GADTs #-} module T where data T a where MkT :: Int -> T Int instance Functor T where fmap f (MkT a) = MkT (f a) }}} it will be rejected: {{{ T.hs:8:22: Could not deduce (b ~ Int) from the context (a ~ Int) bound by a pattern with constructor MkT :: Int -> T Int, in an equation for ?fmap? at T.hs:8:13-17 ?b? is a rigid type variable bound by the type signature for fmap :: (a -> b) -> T a -> T b at T.hs:8:5 Expected type: T b Actual type: T Int Relevant bindings include f :: a -> b (bound at T.hs:8:10) fmap :: (a -> b) -> T a -> T b (bound at T.hs:8:5) In the expression: MkT (f a) In an equation for ?fmap?: fmap f (MkT a) = MkT (f a) }}} On the other hand, {{{Foldable}}} instances do not require the last type argument to be truly polymorphic, since all of the {{{Foldable}}} methods only parameterize {{{t}}} over a single type variable: {{{ class Foldable t where fold :: Monoid m => t m -> m foldMap :: Monoid m => (a -> m) -> t a -> m foldr :: (a -> b -> b) -> b -> t a -> b foldr' :: (a -> b -> b) -> b -> t a -> b foldl :: (b -> a -> b) -> b -> t a -> b foldl' :: (b -> a -> b) -> b -> t a -> b foldr1 :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a toList :: t a -> [a] null :: t a -> Bool length :: t a -> Int elem :: Eq a => a -> t a -> Bool maximum :: forall a. Ord a => t a -> a minimum :: forall a. Ord a => t a -> a sum :: Num a => t a -> a product :: Num a => t a -> a }}} As a result, the type parameter can be safely constrained. If you plug in the code that {{{DeriveFoldable}}} would (hypothetically) generate for {{{T}}}: {{{#!hs {-# LANGUAGE GADTs #-} module T where data T a where MkT :: Int -> T Int instance Foldable T where foldr f z (MkT a) = f a z foldMap f (MkT a) = f a }}} it compiles without problems, since pattern-matching on the GADT constructor specializes {{{foldr}}} to the type {{{(Int -> b -> b) -> b -> T Int -> b}}} and {{{foldMap}}} to the type {{{Monoid m => (Int -> m) -> T Int -> m}}}. Again, this only works with {{{Foldable}}} since the type signatures of its methods allow for {{{t a}}} to be refined safely. {{{Functor}}} and {{{Traversable}}} do not permit this, so the universal polymorphism check would still apply for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 01:44:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 01:44:12 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.67ef041040e63aab3916b4aec48a906b@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Comment (by Rufflewind): Replying to [comment:4 thomie]: > But escaped single quotes are still ok? That's what was used before 525856. Before 525856, it was invoked like this (contains a double-quote only): {{{ ? -e 'config.compiler="$(TEST_HC)"' }}} Now it's invoked like this (with a double-quote 'and an escaped double- quote'): {{{ ? -e 'config.compiler="\"$(TEST_HC)\""' }}} The escaped double-quote is what's tripping up MinGW (an escaped single- quote would cause the same problem). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 01:48:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 01:48:51 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.2fde8d54e990731f5221755376770073@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): I am reasonably certain that this is the same problem as #10375. Running: {{{ inplace/bin/ghc-stage2 +RTS -Ds -Di -Dw -DG -Dg -Db -DS -Dt -Dp -Da -Dl -Dm \ -Dc -Dr }}} otherwise know as "all the damn debug flags I can find" results in: {{{ stg_ap_v_ret... FUN/1(0x7f99ceba88, 0x7f98f041b9, 0x7f98f05448, 0x7f98f084c8, 0x7f98f084d8, 0x7f993cb861, 0x7f98f08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d#, 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() 7f98eff1f0: cap 0: thread 2 stopped (yielding) 7f98eff1f0: giving up capability 0 7f98eff1f0: passing capability 0 to bound task 0x7f990ff000 7f990ff000: woken up on capability 0 7f990ff000: resuming capability 0 7f990ff000: cap 0: running thread 1 (ThreadRunGHC) Segmentation fault }}} which just like trac #10375 is GHC crashing in the `schedule` function of `rts/Schedule.c` with `what_next == ThreadRunGHC`. Will keep this open just in case its not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 02:08:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 02:08:49 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.bf70899292b6578f051b9e65b7e8a33b@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): `Foldable` is safe in the presence of any constraint at all on `a`. It doesn't ever produce one, just consumes them. All occurrences of `a` in the `Foldable` dictionary are in negative position, and it can safely ignore any constraints on `a` you put in place. `Functor` and `Traversable` need to keep the check, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 02:10:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 02:10:47 -0000 Subject: [GHC] #10448: Implement rest of "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> References: <042.2a13dedaa488c75793ff62c67a501b4f@haskell.org> Message-ID: <057.145e0b6b4f5f1bef5ddb4cc40d38fa9e@haskell.org> #10448: Implement rest of "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9682 | Blocking: | Differential Revisions: Phab:D336 -------------------------------------+------------------------------------- Comment (by ekmett): I'll happily set up the API changes in `bifunctors` to match what we want to have move into `base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 03:12:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 03:12:52 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.3f4702fdbc5a21d7e4ed523f6684f947@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Debian's `clang` compiler is also busted when using `-fsanitize=address`, but its seems that Debian's `gcc-5` compiles the above C program correctly. Also note that #10383 (on AArch64/Arm64) is likely to be the same bug as this one. Wonder if a 64 bit address space might make it easier to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 05:27:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 05:27:58 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.3023fd59429ab10791e0958ba14ee634@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Got GHC compiling with `gcc-5 -fsanitize=address` and AddressSanitizer did not find anything to complain about, but `ghc-stage2` still crashes with either a segfault or an illegal instruction depending on where it jumps to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 07:03:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 07:03:54 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.93166f79cb57b14f03de5eb100062484@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Comment (by thomie): Actually, I don't see what is wrong with 525856. These are the 2 relevant changes. In `mk/test.mk`: {{{ - -e 'config.compiler="$(TEST_HC)"' \ + -e 'config.compiler="\"$(TEST_HC)\""' \ }}} In `config/ghc`: {{{ - h = os.popen('"' + config.compiler + '" --info', 'r') + h = os.popen(config.compiler + ' --info', 'r') }}} That should give the same result, shouldn't it? In mk/test.mk there are 3 pairs of quotes: * outer ' : this is a shell string * outer " : this is a python string * inner " : this is a path -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 07:25:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 07:25:33 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.1b37097cda4c01222edbc856630d562c@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: -------------------------------+------------------------------------------- Comment (by thomie): Ok, now I understand, sorry for taking so long. The MINGW magic should happen *before* the string reaches Python, as you said. And now it doesn't, because the string is too heavily quoted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 10:31:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 10:31:28 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.af3063240c1ec6cfabcbef62067d92ee@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I have rooted out another cause for indeterminism and the Debian reproducibilty project managed to compile GHC with a bit-wise identical output: https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html See Phab:D910 for a patch. I doubt that this solves the problem completely, but it is a step towards it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 13:24:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 13:24:14 -0000 Subject: [GHC] #10450: RankNTypes type check on pattern match of "let" behaves different from "case" Message-ID: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> #10450: RankNTypes type check on pattern match of "let" behaves different from "case" -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Operating System: Unknown/Multiple Keywords: RankNTypes | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching, "let/where" and "case" have different behaviours. I believe this to be a bug, and my hope is that all of the following should be accepted. Currently, this is accepted (a version using 'where' instead of 'let' type-checks too): {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Main where data Phantom x = Phantom Int deriving Show foo :: forall y. (forall x. (Phantom x)) -> Phantom y foo (Phantom x) = Phantom (x+1) -- trying to map foo over a list, this is the only way I can get it to work typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] _ -> let (phead:ptail) = intList in foo phead : typeAnnotatedMap ptail }}} The following are not accepted: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] (phead:ptail) -> foo phead : typeAnnotatedMap ptail typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap [] = [] typeAnnotatedMap (phead:ptail) = foo phead : typeAnnotatedMap ptail }}} The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change GHC's behaviour in the following example, for which I understand (but don't like) that it is not accepted, its error message is fine: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap lst = map foo lst }}} Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. Sorry for not testing this on the latest version. Should this not be a bug, it would help if the type checker would somehow point me in the direction of the solution (first version) when I write any one of the 'problem cases'. The current type error is something like: {{{ Couldn't match type ?x0? with ?x? because type variable ?x? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [Phantom x] }}} More helpful would be something like: {{{ Your pattern match bound the following types to a shared skolem variable: ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) phead :: Phantom x0 (bound at rankNtest.hs:11:19) You may have intended to use a "let" or "where" pattern-match instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 13:31:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 13:31:31 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.7f9c2af9fbc1656aa743044b1b95043b@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D911 * milestone: => 7.12.1 Comment: Can you test if the patch in Phab:D911 works (after it validates)? You should be able apply it by running 'arc patch --nobranch D911' and ignoring the warning about the parent commit not existing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 14:00:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 14:00:25 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD Message-ID: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple ConstraintKinds | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following file works in GHC 7.10.1, but fails in HEAD: {{{ {-# LANGUAGE ConstraintKinds #-} module ConstraintKinds where type ManyEq a = (Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a -- Comment this line to make compilation succeed in HEAD ) }}} This is most likely due to ffc21506894c7887d3620423aaf86bc6113a1071, which has set a limit on constraint tuples to size `8`. I think we should either: - increase the size limit on constraint tuples to be the same as normal tuples (`62`), or, - automatically nest constraint kinds beyond 8-tuples, or, - carefully document this limitation for the next release. Note that I encountered this limitation in my own code that I and others actually use: http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/src/CLaSH-Sized-Fixed.html#ENumSFixedC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 14:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 14:06:57 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.ce9d69f481e502d749993d1165ad66a2@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by darchon: Old description: > The following file works in GHC 7.10.1, but fails in HEAD: > > {{{ > {-# LANGUAGE ConstraintKinds #-} > module ConstraintKinds where > > type ManyEq a > = (Eq a > ,Eq a > ,Eq a > ,Eq a > ,Eq a > ,Eq a > ,Eq a > ,Eq a > ,Eq a -- Comment this line to make compilation succeed in HEAD > ) > }}} > > This is most likely due to ffc21506894c7887d3620423aaf86bc6113a1071, > which has set a limit on constraint tuples to size `8`. > > I think we should either: > - increase the size limit on constraint tuples to be the same as normal > tuples (`62`), or, > - automatically nest constraint kinds beyond 8-tuples, or, > - carefully document this limitation for the next release. > > Note that I encountered this limitation in my own code that I and others > actually use: http://hackage.haskell.org/package/clash- > prelude-0.7.5/docs/src/CLaSH-Sized-Fixed.html#ENumSFixedC New description: The following file works in GHC 7.10.1, but fails in HEAD: {{{ {-# LANGUAGE ConstraintKinds #-} module ConstraintKinds where type ManyEq a = (Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a -- Comment this line to make compilation succeed in HEAD ) }}} The error that I get on HEAD is: {{{ [1 of 1] Compiling ConstraintKinds ( ConstraintKinds.hs, interpreted ) ConstraintKinds.hs:5:5: error: Can't find interface-file declaration for type constructor or class (%,,,,,,,,%) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the type ?(Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a)? In the type declaration for ?ManyEq? Failed, modules loaded: none. }}} This is most likely due to ffc21506894c7887d3620423aaf86bc6113a1071, which has set a limit on constraint tuples to size `8`. I think we should either: - increase the size limit on constraint tuples to be the same as normal tuples (`62`), or, - automatically nest constraint kinds beyond 8-tuples, or, - carefully document this limitation for the next release. Note that I encountered this limitation in my own code that I and others actually use: http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/src/CLaSH-Sized-Fixed.html#ENumSFixedC -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 15:08:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 15:08:13 -0000 Subject: [GHC] #10446: Fix error message when variables in a static form are not in scope In-Reply-To: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> References: <056.26a3fd24ae2562ca630e032fb0dd5557@haskell.org> Message-ID: <071.b955e1e8ad5e271f275d415bad133b1a@haskell.org> #10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | StaticPointers Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D906 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 15:13:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 15:13:57 -0000 Subject: [GHC] #10410: make install installs haddck.t files In-Reply-To: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> References: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> Message-ID: <061.ee848457e19bbd4e28a6a5a7b417889d@haskell.org> #10410: make install installs haddck.t files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:903 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"388448bcc2e363d1913b5132a36ac7aaa20eafc0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="388448bcc2e363d1913b5132a36ac7aaa20eafc0" Build system: don't install haddock .t files (#10410) When generating a haddock .t file for a library, don't save it in the `dist-install/doc` directory for that library, as then it gets copied to the installation directory during `make install` by `ghc-cabal copy`. Instead, save it a few directories up; putting it next to `haddock-prologue.txt` seemed appropriate. Test Plan: run `make` in `tests/perf/haddock`. Differential Revision: https://phabricator.haskell.org/D903 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 15:15:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 15:15:38 -0000 Subject: [GHC] #10410: make install installs haddck.t files In-Reply-To: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> References: <046.db9df52aa579a48e5e73de56ecc233f7@haskell.org> Message-ID: <061.6c95e5145ad179479d73df93008d8ae3@haskell.org> #10410: make install installs haddck.t files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:903 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 15:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 15:47:17 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.e1b2225694c519dea14b59a69f1ba285@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Comment (by Rufflewind): Unfortunately, the `wrap` call still breaks the magic. The conversion seems to be documented here: http://www.mingw.org/wiki/Posix_path_conversion What is the reason for quoting `compiler.config`? A quick grep shows the following code use `compiler.config`: {{{ ./testsuite/config/ghc:config.compiler = 'ghc' ./testsuite/config/ghc: h = os.popen(config.compiler + ' --info', 'r') ./testsuite/config/ghc: h = os.popen(config.compiler + ' +RTS --info', 'r') ./testsuite/mk/test.mk: -e 'config.compiler=$(call quote_path,$(TEST_HC))' \ ./testsuite/driver/testglobals.py: self.compiler = '' ./testsuite/driver/runtests.py: # testframe -e 'config.compiler=ghc-5.04' }}} There might be others I've missed, but I think in many situations the quotes will either get stripped anyway, or can be rewritten using `subprocess` so as to avoid the need for them. If quotes are necessary, they could be just added at those specific places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 15:50:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 15:50:53 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.064f475e088bfa8fd6a6a666c7cb3842@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D901 -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c5911479f295242e16e396eb5d1369f2e4ce8de0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c5911479f295242e16e396eb5d1369f2e4ce8de0" ApiAnnotations tweaks Summary: A collection of minor updates for the API Annotations. 1. The annotations for the implicity parameter is disconnected in the following type MPI = ?mpi_secret :: MPISecret 2. In the following, the annotation for one of the commas is disconeected. mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form) 3. In the following, the annotation for the parens becomes disconnected data MaybeDefault v where SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) Test Plan: ./validate Reviewers: hvr, austin Reviewed By: austin Subscribers: bgamari, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D901 GHC Trac Issues: #10399 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 16:24:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 16:24:06 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.216c3c66b538cbce7ff8b90768ce4f5f@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:8 Austin Seipp ]: > In [changeset:"470a94947b076cb74a6adcbcf9b39057a67e1fba/ghc"]: > {{{ > [...] > It apparently made Harbormaster sad. > }}} Do you have details on what went wrong with Harbormaster? Linking all libraries looked to me like the most promising way to do dynamic linking in the future and also to implement library unload. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 16:26:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 16:26:39 -0000 Subject: [GHC] #10452: ApiAnnotations : rationalise tests Message-ID: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> #10452: ApiAnnotations : rationalise tests -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment the API Annotations tests have a driver that has been copy/pasted multiple times. Compile it once, and run it for each test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 16:27:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 16:27:09 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.1191524c9accfbe864a609a6ebcfd11b@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:4 George]: > Not sure but the -flat_namespace option might be what you are looking for. How bad as in breaking assumptions made by MacOS would it be to use `-flat_namespace`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 16:34:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 16:34:34 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator In-Reply-To: <047.abf3d61d6edeed38824d04625109fece@haskell.org> References: <047.abf3d61d6edeed38824d04625109fece@haskell.org> Message-ID: <062.4b7486cb9735ef437effb498acbe5d97@haskell.org> #9863: Provide PowerPC 64 bit native code generator ------------------------------------+------------------------------------ Reporter: trommler | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D629 ------------------------------------+------------------------------------ Comment (by trommler): I updated Phab:D629 and we now have both ABIs, ELF 1.9 (big endian) and ELF 2 (little endian). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 17:16:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 17:16:10 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.5b372a7a7a9f32fd6c233e26327b2067@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 19:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 19:30:31 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci Message-ID: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In ghci, most block heralds trigger the multiline mode when :set +m is on. However, \case does not (and should). Compare: {{{ Prelude> ($True) (\case Prelude| x -> x Prelude| ) True Prelude> ($True) $ \case :11:11: Empty list of alternatives in case expression Use EmptyCase to allow this }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 19:52:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 19:52:35 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.0a3f9fb8cdbd1bc6a6301b298cf92ae0@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D901 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 20:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 20:37:39 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset Message-ID: <050.2db21865438175ee626af0337216c86d@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: | Owner: MetaMemoryT | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Windows Keywords: | Type of failure: Incorrect Architecture: x86_64 | warning at compile-time (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Getting this any time I compile anything. {{{ ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 20:42:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 20:42:29 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset In-Reply-To: <050.2db21865438175ee626af0337216c86d@haskell.org> References: <050.2db21865438175ee626af0337216c86d@haskell.org> Message-ID: <065.34b299156e527da449594f793b69dcf1@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: MetaMemoryT | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by MetaMemoryT: Old description: > Getting this any time I compile anything. > > {{{ > ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: WSAStartup from ws2_32 is linked instead of > __imp_WSAStartup > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept > ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of > __imp_inet_ntoa > ghc.exe: warning: getnameinfo from ws2_32 is linked instead of > __imp_getnameinfo > ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of > __imp_getaddrinfo > ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of > __imp_freeaddrinfo > ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of > __imp_LeaveCriticalSection > ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of > __imp_EnterCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > }}} New description: Getting strange linker warning anytime I compile anything. note: I am using minghc distribution: https://github.com/fpco/minghc/releases/download/2015-05-26/minghc-7.10.1-x86_64.exe {{{ ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 20:55:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 20:55:12 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset In-Reply-To: <050.2db21865438175ee626af0337216c86d@haskell.org> References: <050.2db21865438175ee626af0337216c86d@haskell.org> Message-ID: <065.8c774b822a23570ff799c527d43e6b5b@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: MetaMemoryT | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by MetaMemoryT: Old description: > Getting strange linker warning anytime I compile anything. > > note: I am using minghc distribution: > https://github.com/fpco/minghc/releases/download/2015-05-26/minghc-7.10.1-x86_64.exe > > {{{ > ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: WSAStartup from ws2_32 is linked instead of > __imp_WSAStartup > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept > ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of > __imp_inet_ntoa > ghc.exe: warning: getnameinfo from ws2_32 is linked instead of > __imp_getnameinfo > ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of > __imp_getaddrinfo > ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of > __imp_freeaddrinfo > ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of > __imp_LeaveCriticalSection > ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of > __imp_EnterCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > }}} New description: Getting strange linker warning anytime I compile `cabal test` from https://github.com/prowdsponsor/esqueleto. note: I am using minghc distribution: https://github.com/fpco/minghc/releases/download/2015-05-26/minghc-7.10.1-x86_64.exe {{{ ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 20:55:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 20:55:35 -0000 Subject: [GHC] #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset In-Reply-To: <050.2db21865438175ee626af0337216c86d@haskell.org> References: <050.2db21865438175ee626af0337216c86d@haskell.org> Message-ID: <065.ae0b636c468de36581814ec5b50deb59@haskell.org> #10454: ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -------------------------------------+------------------------------------- Reporter: MetaMemoryT | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by MetaMemoryT: Old description: > Getting strange linker warning anytime I compile `cabal test` from > > https://github.com/prowdsponsor/esqueleto. > > note: I am using minghc distribution: > https://github.com/fpco/minghc/releases/download/2015-05-26/minghc-7.10.1-x86_64.exe > > {{{ > ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: WSAStartup from ws2_32 is linked instead of > __imp_WSAStartup > ghc.exe: warning: WSACleanup from ws2_32 is linked instead of > __imp_WSACleanup > ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept > ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of > __imp_inet_ntoa > ghc.exe: warning: getnameinfo from ws2_32 is linked instead of > __imp_getnameinfo > ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of > __imp_getaddrinfo > ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of > __imp_freeaddrinfo > ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of > __imp_LeaveCriticalSection > ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of > __imp_EnterCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead > of __imp_DeleteCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > ghc.exe: warning: InitializeCriticalSection from kernel32 is linked > instead of __imp_InitializeCriticalSection > }}} New description: Getting strange linker warning anytime I compile `cabal test` on https://github.com/prowdsponsor/esqueleto. note: I am using minghc distribution: https://github.com/fpco/minghc/releases/download/2015-05-26/minghc-7.10.1-x86_64.exe {{{ ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 21:15:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 21:15:26 -0000 Subject: [GHC] #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS Message-ID: <045.a9028fd77ac5d315b33e56f253825d09@haskell.org> #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using ghc's heap profiling, some allocations are treated specially in such a way that we get no useful information for them. * For +RTS -hc "cost centre stack", the allocations are classed as PINNED, which means we cannot see which cost centre allocated them. * For +RTS -hm "module", the allocations are classed as SYSTEM, which means we cannot see which module allocated them. * For +RTS -hy "type description" and +RTS -hd "closure description", the allocations are classed as ARR_WORDS, which means we cannot see what type they are (ByteArray#?). So none of these modes help us see what these allocations are or where they come from. Do these allocations have to be treated in this special way such that we loose all useful information? Presumably they are pinned ByteArray#s, but surely we can still track which cost centre to assign them to, and hence the module, and shouldn't the type/closure description be "ByteArray#" or "pinned ByteArray#" or something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 21:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 21:50:00 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation Message-ID: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It appears that during cross-compilation the build system uses the wrong compiler as C preprocessor. It may cause errors by passing incompatible flags to the cross-compiler --- for example when trying to cross-compile using 32-bit clang on a 64-bit system (sample output attached below). {{{ /Users/jakub/src/nacl_sdk/pepper_canary/toolchain/mac_pnacl/bin/pnacl- clang -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -m64 -fno-stack-protector -Wall -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/proce_0hwN3CTKynhHQqQkChnSdH/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/direc_3TcTyYedch32o1zTH2MR00/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/time_Hh2clZW6in4HpYHx5bLtb7/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/bytes_6vj5EoliHgNHISHCVCb069/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include' -isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/include' -Wno-unknown-pragmas -MM -x c compiler/ghci/keepCAFsForGHCi.c -MF compiler/stage1/build/.depend-v.c_asm.bit pnacl-clang: Unrecognized option: -m64 Use '--help' for more information. make[1]: *** [compiler/stage1/build/.depend-v.c_asm] Error 255 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 21:54:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 21:54:35 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.d9a7b52c6dda47bf52ef1b37e13735f0@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Would probably help if you could attach your `mk/build.mk` file and the arguments you passed to the `./configure` script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 21:59:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 21:59:11 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.7ada9c29be311146bdd853ff7471304d@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * keywords: => cross-compiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 21:59:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 21:59:29 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.f86f74b4eda2e2dcf5e164d7fd480d1c@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 22:08:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 22:08:21 -0000 Subject: [GHC] #10456: Wrong CPP during cross-compilation In-Reply-To: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> References: <046.462d8102e6aedbc950f7c67c721714d1@haskell.org> Message-ID: <061.6a7a9af0a8e9c7be5fb7ba0b18ba0caf@haskell.org> #10456: Wrong CPP during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I can reproduce this with just `./configure --target=i386-unknown-linux`, though using the wrong CPP to build dependencies has no visibly bad effects in my case. The OP's immediate issue is that the build system knows it is doing a build for the host system, so it added `-m64`, but then actually used the cross-compiler for CPP. I wonder whether, until recently (when the stage1 compiler gained some TH support), it was the case that there was no C code in the compiler proper (as opposed to the rts and libraries)? I guess we need separate CPP_STAGEn variables, or to have the dependency generation use CC rather than CPP... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 22:56:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 22:56:10 -0000 Subject: [GHC] #10450: Poor type error message when an argument is insufficently polymorphic (was: RankNTypes type check on pattern match of "let" behaves different from "case") In-Reply-To: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> References: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> Message-ID: <064.b546fe8be0d29f46399ca10d6e3a4442@haskell.org> #10450: Poor type error message when an argument is insufficently polymorphic -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: RankNTypes Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Old description: > When pattern matching, "let/where" and "case" have different behaviours. > I believe this to be a bug, and my hope is that all of the following > should be accepted. > > Currently, this is accepted (a version using 'where' instead of 'let' > type-checks too): > {{{#!hs > {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} > module Main where > > data Phantom x = Phantom Int deriving Show > > foo :: forall y. (forall x. (Phantom x)) -> Phantom y > foo (Phantom x) = Phantom (x+1) > -- trying to map foo over a list, this is the only way I can get it to > work > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap intList = case intList of > [] -> [] > _ -> let (phead:ptail) = intList > in foo phead : typeAnnotatedMap ptail > }}} > > The following are not accepted: > {{{#!hs > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap intList = case intList of > [] -> [] > (phead:ptail) -> foo phead : > typeAnnotatedMap ptail > > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap [] = [] > typeAnnotatedMap (phead:ptail) = foo phead : typeAnnotatedMap ptail > }}} > > The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change > GHC's behaviour in the following example, for which I understand (but > don't like) that it is not accepted, its error message is fine: > {{{#!hs > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap lst = map foo lst > }}} > > Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. > Sorry for not testing this on the latest version. > > Should this not be a bug, it would help if the type checker would somehow > point me in the direction of the solution (first version) when I write > any one of the 'problem cases'. The current type error is something like: > {{{ > Couldn't match type ?x0? with ?x? > because type variable ?x? would escape its scope > This (rigid, skolem) type variable is bound by > a type expected by the context: [Phantom x] > }}} > More helpful would be something like: > > {{{ > Your pattern match bound the following types to a shared skolem variable: > ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) > phead :: Phantom x0 (bound at rankNtest.hs:11:19) > You may have intended to use a "let" or "where" pattern-match instead. > }}} New description: When pattern matching, "let/where" and "case" have different behaviours. I believe this to be a bug, and my hope is that all of the following should be accepted. Currently, this is accepted (a version using 'where' instead of 'let' type-checks too): {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Main where data Phantom x = Phantom Int deriving Show foo :: forall y. (forall x. (Phantom x)) -> Phantom y foo (Phantom x) = Phantom (x+1) -- trying to map foo over a list, this is the only way I can get it to work typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] _ -> let (phead:ptail) = intList in foo phead : typeAnnotatedMap ptail }}} The following are not accepted: {{{#!hs typeAnnotatedMap1 :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap1 intList = case intList of [] -> [] (phead:ptail) -> foo phead : typeAnnotatedMap1 ptail typeAnnotatedMap2 :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap2 [] = [] typeAnnotatedMap2 (phead:ptail) = foo phead : typeAnnotatedMap2 ptail }}} The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change GHC's behaviour in the following example, for which I understand (but don't like) that it is not accepted, its error message is fine: {{{#!hs typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap lst = map foo lst }}} Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. Sorry for not testing this on the latest version. Should this not be a bug, it would help if the type checker would somehow point me in the direction of the solution (first version) when I write any one of the 'problem cases'. The current type error is something like: {{{ Couldn't match type ?x0? with ?x? because type variable ?x? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [Phantom x] }}} More helpful would be something like: {{{ Your pattern match bound the following types to a shared skolem variable: ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) phead :: Phantom x0 (bound at rankNtest.hs:11:19) You may have intended to use a "let" or "where" pattern-match instead. }}} -- Comment (by simonpj): Why don't you write {{{ typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap x = x }}} which works just fine? To answer your specific question, `let` does generalisation, while `case` does not. * In `typeAnnotatedMap`, the type of `ptail` is generalised (by the `let`) to `forall a. [Phantom a]`. So the `typeAnnotatedMap` has an argument that is sufficiently polymorphic. * In `typeAnnotatedMap1`, the type of `ptail` is `[Phantom x0]`, where the call to `intList` (in `case intList of...`) is instantiated at type `x0`. But that means that the call `typeAnnotatedMap1 ptail` fails, because the type of `ptail` is insufficiently polymorphic. So I don't think this is a bug. I grant that error messags for insufficiently-polymorphic arguments are not good; so I'll leave this ticket open for that treason, with a new title. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 23:18:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 23:18:07 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.35fbd01cf8c6171e9242e807ad9c3438@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK, but can I ask: can you say precisely what `Foldable` code you would expect to get for these two data types? {{{ data T1 a where MkT1 :: (a~Int) => a -> T1 a data T2 a where MkT2 :: Int -> T2 Int data T3 a where MkT3 :: (a~Int) => a -> T3 Int }}} All three are equivalent. But I am guessing that you intend that they are '''not equivalent''' to the "deriving `Foldable`" algorithm? If so, that had better be clearly stated in the user manual. (Regrettably, the user manual is silent on how `Foldable`, `Traversable`, and `Functor` are generated. It'd be jolly good to have a wiki page that explained the deriving algorithm; [https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011 here's how it's done for Eq/Ord etc].) The documentation is probably the hard bit. The change to lift the condition is pretty easy: look at `TcDeriv.cond_functorOK`. (This same function actually handles `Traversable` and `Foldable`. A little refactoring would be needed to distinguish the `Foldable` case, perhaps by passing the class name instead of a boolean to the function.) I'd be happy to review a patch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 27 23:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 May 2015 23:47:46 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.a80e0705eeeaba02af39ae8786f418d4@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): The code that I would expect {{{DeriveFoldable}}} to derive for {{{T1}}}, {{{T2}}}, or {{{T3}}} would be: {{{#!hs instance Foldable T where foldr f z (MkT a) = f a z foldMap f (MkT a) = f a }}} which is the same code that you would get for {{{data T a = MkT a deriving Foldable}}}. I don't believe this would require any change to the {{{deriving Foldable}}} algorithm (but I'm not intimately familiar with the implementation details). I agree that it would be nice to have more documentation on the algorithms themselves. I gained a better intuition for the [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1476 Functor], [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1725 Foldable], and [http://git.haskell.org/ghc.git/blob/9f968e97a0de9c2509da00f6337b612dd72a0389:/compiler/typecheck/TcGenDeriv.hs#l1800 Traversable] algorithms by reading the comments in {{{TcGenDeriv.hs}}}. For example, here's a somewhat formal description of how {{{deriving Foldable}}} works: {{{ The cases are: $(foldr 'a 'b) = \x z -> z -- when b does not contain a $(foldr 'a 'a) = f $(foldr 'a '(b1,b2)) = \x z -> case x of (x1,x2) -> $(foldr 'a 'b1) x1 ( $(foldr 'a 'b2) x2 z ) $(foldr 'a '(T b1 b2)) = \x z -> foldr $(foldr 'a 'b2) z x -- when a only occurs in the last parameter, b2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 00:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 00:04:22 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists Message-ID: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Recently, Simon Marlow asked why the list instance for Traversable had a custom mapM implementation that used the Monad operations. Having looked a bit, I don't think there's any good reason. The only fusion that the custom mapM can participate in is due to it being written as foldr, but traverse is, as well. So as long as 'mapM = traverse' is able to inline appropriately, there should be no difference. Further, this can be changed, in principle, for 7.10.2. It doesn't change any types, only the implementation. mapM = traverse is the class default definition, so this could possibly be completed by just removing the custom definition. Link to the libraries thread: https://mail.haskell.org/pipermail/libraries/2015-May/025708.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 00:34:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 00:34:50 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.8d9532f11efab3fd32a7cef1c7a1472a@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shachaf): You expect that the `Foldable` instance for `data T2 a = (a ~ Int) => MkT2 Int` give you the `Int` because there happens to be an `Int` equality constraint? That seems pretty unintuitive to me. What about e.g. `data E = E Int`, and `data A a = A E` vs. `data A a = (a ~ Int) => A E`, and then inlining E? I think Simon's examples are worth thinking about, and derived `Foldable` instances in the presence of equality constraints need some more justification. It's true that `Foldable` is the wild west of type classes, so parametricity doesn't give us the right answer like for `Functor`, but I don't expect it to just look for types that happen to be equal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 01:18:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 01:18:54 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.897beda463d56cbaa06b65d271da37d7@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Narrowed the problem down to code in `rts/sm/Evac.c` namely: {{{ do { info_ptr = xchg((StgPtr)&p->header.info, (W_)&stg_WHITEHOLE_info); } while (info_ptr == (W_)&stg_WHITEHOLE_info); }}} Adding a `printf` before and after the call to `xchg` found that the exchange was happening, but the function was returning `0` instead of the old value of `p->header.info`. Wrote a small program to test this: {{{ #include "PosixSource.h" #include "Rts.h" #include "Stg.h" #include "stg/Types.h" #include "stg/SMP.h" int main (void) { StgWord a = 0xa, b = 0xb, res = 1; printf ("0x%lx 0x%lx 0x%lx\n", res, a, b); res = xchg(&a, b); printf ("0x%lx 0x%lx 0x%lx\n", res, a, b); return 0; } }}} which I compile and run as: {{{ gcc-5 -Wall -O3 -Iincludes -Irts -fno-stack-protector -DTHREADED_RTS \ -DCOMPILING_RTS xchg_test.c -o xchg_test && ./xchg_test }}} which on AArch64/Arm64 results: {{{ 0x1 0xa 0xb 0x0 0xb 0xb }}} which is just profoundly wrong! The expected result is: {{{ 0x1 0xa 0xb 0xa 0xb 0xb }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 01:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 01:38:48 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.4583a984787d5b3042423175438199e6@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): > You expect that the {{{Foldable}}} instance for {{{data T2 a = (a ~ Int) => MkT2 Int}}} give you the {{{Int}}} because there happens to be an {{{Int}}} equality constraint? That is what I am expecting, yes, especially since {{{T1}}}, {{{T2}}}, and {{{T3}}} are equivalent representations of the same thing. > That seems pretty unintuitive to me. What about e.g. {{{data E = E Int}}}, and {{{data A a = A E}}} vs. {{{data A a = (a ~ Int) => A E}}}, and then inlining E? I'm not sure how inlining would cause a derived {{{Foldable}}} instance for {{{data A a = (a ~ Int) => A E}}} to fail. Does inlining occur before {{{DeriveFoldable}}} generates its code? If so, I don't see how GHC could confuse {{{E}}} for {{{Int}}}. > derived {{{Foldable}}} instances in the presence of equality constraints need some more justification. I find myself wanting to derive {{{Foldable}}} instances for deeply embedded DSLs that are represented as GADTs. Here's a simple example from [https://github.com/ku-fpg/hermit- ghci/blob/8a7556bc53a2e79fb46a807875e913d753b5da37/src/HERMIT/API.hs#L57-58 hermit-ghci]: {{{#!hs data ShellEffect :: * -> * where ShellEffect :: Value -> ShellEffect () }}} (which could equivalently be represented as {{{ShellEffect :: a ~ () => Value -> ShellEffect a}}}) This isn't a {{{Functor}}} or {{{Traversable}}}, but it readly admits a {{{Foldable}}} instance which {{{DeriveFoldable}}} would be able to infer: {{{#!hs instance Foldable ShellEffect where foldr f z (ShellEffect a) = z foldMap f (ShellEffect a) = mempty }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 01:58:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 01:58:12 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.284f764b868a34eb21764df00a0aa926@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm probably making an assumption about how robust GHC's equality constraint solver is, but I would think that it'd be capable enough to infer whether an argument's type is equal to the type parameter. If it were undecidable, then wouldn't this (legal) code have to be rejected? {{{#!hs data S a b where MkS :: (a ~ Int) => Int -> S a b deriving instance Foldable (S a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 02:37:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 02:37:43 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.30306b88333db64cc3969769ac34e1d7@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dolio): Also, for instance {{{ data Refine a where RefineI :: Refine Int RefineD :: Refine Double data Foo a = Foo (Refine a) Int }}} Should a `Foldable` instance for `Foo` test the `Refine a` and fold over the `Int` if it's `RefineI`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 02:59:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 02:59:55 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.ce99966fcbf973073795a039ebe58087@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 dolio]: > Also, for instance > > {{{ > data Refine a where > RefineI :: Refine Int > RefineD :: Refine Double > > data Foo a = Foo (Refine a) Int > }}} > > Should a `Foldable` instance for `Foo` test the `Refine a` and fold over the `Int` if it's `RefineI`? I assume that {{{Refine}}} is also an instance of {{{Foldable}}}? If so, the respective derived {{{Foldable}}} instances of {{{Refine}}} and {{{Foo}}} would be: {{{#!hs instance Foldable Refine where foldr f z RefineI = z foldr f z RefineD = z foldMap f RefineI = mempty foldMap f RefineD = mempty instance Foldable Foo where foldr f z (Foo a1 a2) = foldr f z a1 foldMap f (Foo a1 a2) = mappend (foldMap f a1) mempty }}} So no, the derived instance wouldn't fold over the {{{Int}}}, since the {{{Foldable Foo}}} instance would never pattern match on a constructor of {{{Refine}}}. I don't see this as a problem, especially since this seems consistent with the behavior of {{{deriving Generic1}}} statements, which also check if a field has the same type as the last type parameter. For example, if you derived a {{{Generic1}}} instance for {{{Foo}}}, it would give: {{{#!hs type Rep1 Foo = D1 D1Foo (C1 C1_0Foo (S1 NoSelector (Rec1 Refine) :*: S1 NoSelector (Rec0 Int))) }}} So {{{deriving Generic1}}} would also consider the {{{a}}} in {{{Refine a}}} to be distinct from {{{Int}}}, as evidenced by their differing {{{Rec1}}} and {{{Rec0}}} wrappers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 03:14:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 03:14:45 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) Message-ID: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -----------------------------------------+--------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi: {{{ % cabal repl Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get: {{{ % cabal repl --ghc-options="-fPIC" Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FYI the C type of `pcre_callout` is a little unusual: {{{ extern int (*pcre_callout)(pcre_callout_block *); }}} In other words it is a global variable (pointer to function), not a function itself. Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 03:21:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 03:21:23 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.7b7f3bf3eb667f6e1653d53b73db405a@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dolio): I'm not asking if GHC would derive the instance I specified. I'm asking whether it's an okay `Foldable` instance based on the same reasoning as for: {{{ data Bar a where Bar :: (a ~ Int) -> Int -> Bar a }}} and the like. "Can we automatically do this," is not the only relevant question. "Should we do this and why," also matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 03:42:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 03:42:49 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.f8dd39a490b7142867c14d1e3bc00e44@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think it's entirely reasonable for a derived {{{Foldable Foo}}} instance not to fold over the {{{Int}}} argument. If it did fold over the {{{Int}}} argument, then the implementation of {{{foldr}}} and {{{foldMap}}} would have to pattern-match the {{{Refine}}} argument, making it resemble this: {{{#!hs instance Foldable Foo where foldr f z (Foo RefineI a2) = f a2 z foldr f z (Foo RefineD a2) = z foldMap f (Foo RefineI a2) = mappend mempty (f a2) foldMap f (Foo RefineD a2) = mappend mempty mempty }}} At this point, though, we are no longer defining {{{foldr}}} and {{{foldMap}}} in terms of the {{{Foldable Refine}}}. This feels off to me, since 1. Almost every other {{{deriving}}} typeclass extension dispatches to arguments' implementations of that particular typeclass (e.g., in {{{data Bar a = Bar (Maybe a) [a] deriving Show}}}, the derived {{{Show (Bar a)}}} instance relies on the {{{Show}}} instances for {{{Maybe a}}} and {{{[a]}}}). 2. If a user were to manually define an "untraditional" {{{Foldable}}} instance for {{{Refine}}}, the derived {{{Foldable Foo}}} instance wouldn't make use of it. In addition, requiring derived instances to pattern-match constructors of GADT arguments could break other code, e.g., {{{#!hs data Refine a where RefineI :: Refine Int RefineD :: Refine Double instance Functor Refine where fmap = undefined data Foo a = Foo (Refine a) Int deriving Functor }}} Since pattern-matching on {{{Refine}}} would refine the type of {{{fmap}}} in the derived {{{Functor Foo}}} instance to something that isn't universally polymorphic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 05:03:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 05:03:40 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.5935eebca57b3d09b19fe958bb28ac79@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: dalaing => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 05:06:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 05:06:07 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.d6f34d443838f75320f0e45a268208f5@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dalaing): jstolarek - sorry I missed you comment - I've been stalled on this for a while as various other things have moved to the front of the queue, so I've unassigned myself for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 09:59:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 09:59:26 -0000 Subject: [GHC] #10447: DeriveFoldable rejects instances with constraints in last argument of data type In-Reply-To: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> References: <050.655803d4d5fe3ef1b8f5abc5e3585493@haskell.org> Message-ID: <065.035a7dc03c811884921cc8f781940f10@haskell.org> #10447: DeriveFoldable rejects instances with constraints in last argument of data type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8678 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Simon's examples definitely give me pause. So putting aside type equality constraints for a moment, the other cases seem unambiguous. This would allow things like {{{ data Set a where Empty :: Set a NonEmpty :: Ord a => Tree a }}} but wouldn't get us {{{ data Val a where Int :: Int -> Val Int Char :: Char -> Val Char }}} To get there, it seems to me that `shachaf`'s `E` example seems a step too far. Given {{{ data Bar a = Bar a data Foo a = Foo (Bar a b) }}} We don't attempt to walk into `Bar` and recursing into something that isn't the last argument or relying on expansion seems "deeply magic", and ill specified -- where does the recursion stop? On the other hand, if we take Simon's examples, and say it'd be nice to generate the same code for semantically equal data declarations, and to allow whatever constraints we want, then using the type equality constraint (a ~ X) as part of the check for naked `a`s and accepting a naked `X` as an `a` seems very coherent. Then in the presence of `(a ~ X)`, folding over all `X`'s immediately inside the structure we're in and delegating all `(f X)`'s to the `Foldable` for `f` would be consistent with the existing behavior. If you wanted something more exotic where you skipped over some of them, you'd have to write a hand-rolled instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 11:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 11:50:09 -0000 Subject: [GHC] #8723: sdist should not have to build everything In-Reply-To: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> References: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> Message-ID: <061.ab2fb6e4cf3004273dc9512ce10ad560@haskell.org> #8723: sdist should not have to build everything -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D917 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D917 * milestone: => 7.12.1 Comment: Took me quite a bit longer then one hour, but I have a patch up in Phab:D917. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 12:35:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 12:35:52 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.510e824204934b38b96d415d015cb6cc@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): With 7.10.1 I see a factor of 2 difference in performance: benchmarking matmultForM_ time 10.90 ?s (10.89 ?s .. 10.91 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 10.89 ?s (10.89 ?s .. 10.91 ?s) std dev 32.72 ns (18.98 ns .. 65.42 ns) benchmarking matmultLoop time 5.404 ?s (5.387 ?s .. 5.419 ?s) 1.000 R? (1.000 R? .. 1.000 R?) mean 5.409 ?s (5.398 ?s .. 5.420 ?s) std dev 37.99 ns (33.64 ns .. 44.26 ns) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 12:37:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 12:37:02 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.cd3a898e3f758127c314e515265fb822@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 13:16:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 13:16:56 -0000 Subject: [GHC] #10450: Poor type error message when an argument is insufficently polymorphic In-Reply-To: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> References: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> Message-ID: <064.dd4cbc1e0bb971c9bca82718ad8516a2@haskell.org> #10450: Poor type error message when an argument is insufficently polymorphic -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: RankNTypes Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by sjcjoosten): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 13:20:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 13:20:12 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.57346b49f68fbece8869281494a1d9da@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Comment (by Thomas Miedema ): In [changeset:"ce166a3aaab28a9b08c60da6d0cfdab998b6e8ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ce166a3aaab28a9b08c60da6d0cfdab998b6e8ca" Testdriver: do not interfer with MinGW path magic (#10449) This should fix the testsuite driver on Windows using the MinGW tools with a native build of Python. MinGW automagically converts MinGW-style paths (e.g. '/c/programs/ghc/bin/ghc') into ordinary Windows paths (e.g. 'C:/programs/ghc/bin/ghc') when a native Windows program is invoked. But it doesn't do so when those paths are wrapped with a pair of escaped double quotes. The fix is to not call `eval` on the paths in Python, which let's us use one less pair of quotes, and makes MinGW happy. Reviewers: Rufflewind, austin Differential Revision: https://phabricator.haskell.org/D911 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 13:23:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 13:23:33 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.a8131d394bcd60e0f0d942f8bc8cd572@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Comment (by thomie): Replying to [comment:9 Rufflewind]: > What is the reason for quoting `compiler.config`? Copy pasting from the comments: {{{ # Wrap non-empty program paths in quotes, because they may contain spaces. Do # it here, so we don't have to (and don't forget to do it) in the .T test # scripts (search for '{compiler}' or '{hpc}'). This may or may not be a good # idea. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 13:26:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 13:26:10 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.2cda41b725cdba88704ce1bc423f0055@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Changes (by thomie): * status: patch => merge * milestone: 7.12.1 => 7.10.2 Comment: Please merge the commit above to ghc-7.10. It depends on 6694ccf9444baf565eb0f38f7808767616f23825, so that one will have to go in as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 13:40:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 13:40:49 -0000 Subject: [GHC] #10450: Poor type error message when an argument is insufficently polymorphic In-Reply-To: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> References: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> Message-ID: <064.03942843c0755027cfe719a05770cb17@haskell.org> #10450: Poor type error message when an argument is insufficently polymorphic -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: RankNTypes Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Old description: > When pattern matching, "let/where" and "case" have different behaviours. > I believe this to be a bug, and my hope is that all of the following > should be accepted. > > Currently, this is accepted (a version using 'where' instead of 'let' > type-checks too): > {{{#!hs > {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} > module Main where > > data Phantom x = Phantom Int deriving Show > > foo :: forall y. (forall x. (Phantom x)) -> Phantom y > foo (Phantom x) = Phantom (x+1) > -- trying to map foo over a list, this is the only way I can get it to > work > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap intList = case intList of > [] -> [] > _ -> let (phead:ptail) = intList > in foo phead : typeAnnotatedMap ptail > }}} > > The following are not accepted: > {{{#!hs > typeAnnotatedMap1 :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap1 intList = case intList of > [] -> [] > (phead:ptail) -> foo phead : > typeAnnotatedMap1 ptail > > typeAnnotatedMap2 :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap2 [] = [] > typeAnnotatedMap2 (phead:ptail) = foo phead : typeAnnotatedMap2 ptail > }}} > > The switches "ImpredicativeTypes" and "NoImpredicativeTypes" only change > GHC's behaviour in the following example, for which I understand (but > don't like) that it is not accepted, its error message is fine: > {{{#!hs > typeAnnotatedMap :: (forall x. [Phantom x]) > -> [Phantom y] > typeAnnotatedMap lst = map foo lst > }}} > > Tested this on 7.8.2. Version 7.6.3 and 7.4.2 seem to behave the same. > Sorry for not testing this on the latest version. > > Should this not be a bug, it would help if the type checker would somehow > point me in the direction of the solution (first version) when I write > any one of the 'problem cases'. The current type error is something like: > {{{ > Couldn't match type ?x0? with ?x? > because type variable ?x? would escape its scope > This (rigid, skolem) type variable is bound by > a type expected by the context: [Phantom x] > }}} > More helpful would be something like: > > {{{ > Your pattern match bound the following types to a shared skolem variable: > ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) > phead :: Phantom x0 (bound at rankNtest.hs:11:19) > You may have intended to use a "let" or "where" pattern-match instead. > }}} New description: When pattern matching, "let/where" and "case" have different behaviours. Currently, this is accepted (a version using 'where' instead of 'let' type-checks too): {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Main where data Phantom x = Phantom Int deriving Show foo :: forall y. (forall x. (Phantom x)) -> Phantom y foo (Phantom x) = Phantom (x+1) -- trying to map foo over a list, this is the only way I can get it to work typeAnnotatedMap :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap intList = case intList of [] -> [] _ -> let (phead:ptail) = intList in foo phead : typeAnnotatedMap ptail }}} The following are not accepted: {{{#!hs typeAnnotatedMap1 :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap1 intList = case intList of [] -> [] (phead:ptail) -> foo phead : typeAnnotatedMap1 ptail typeAnnotatedMap2 :: (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap2 [] = [] typeAnnotatedMap2 (phead:ptail) = foo phead : typeAnnotatedMap2 ptail }}} The current type error is something like: {{{ Couldn't match type ?x0? with ?x? because type variable ?x? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: [Phantom x] }}} More helpful would be something like: {{{ Your pattern match bound the following types to a shared skolem variable: ptail :: [Phantom x0] (bound at rankNtest.hs:11:25) phead :: Phantom x0 (bound at rankNtest.hs:11:19) You may have intended to use a "let" or "where" pattern-match instead. }}} -- Comment (by sjcjoosten): I already emailed this comment, but it did not show up in trac, so I am adding it again (sorry for cross-posting) I agree that there is no bug. To follow up on writing a simpler version (your version does not work, because it does not map "foo"), it can be done using impredicative types, and the helper function "bar": {{{#!hs bar :: (forall x. [Phantom x]) -> [forall x. Phantom x] bar [] = [] bar lst = help h ++ bar tl where (h:tl) = lst help :: (forall x. Phantom x) -> [forall x. Phantom x] help (Phantom x) = [Phantom x] typeAnnotatedMap3 :: forall y. (forall x. [Phantom x]) -> [Phantom y] typeAnnotatedMap3 lst = map foo (bar lst) }}} I don't use Impredicative types because I do not understand them. For example, I don't get why this won't typecheck (bar does the same): {{{#!hs bar2 :: (forall x. [Phantom x]) -> [forall x. Phantom x] bar2 [] = [] bar2 lst = help h : bar2 tl where (h:tl) = lst help :: (forall x. Phantom x) -> forall x. Phantom x help (Phantom x) = Phantom x }}} Since we're improving error messages in this ticket, I would really like to know why the skolemn variable {{{x0}}} (probably arising from {{{forall x. Phantom x}}}) could not be matched to {{{forall x. Phantom x}}}, but the only error I got was: {{{ Couldn't match expected type ?forall x. Phantom x? with actual type ?Phantom x0? In the first argument of ?(:)?, namely ?help h? In the expression: help h : bar tl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 14:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 14:19:08 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.e611a6b4649ae85360b8533d78cade5e@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dolio): `mapM_` is in a similar situation, despite not being in the `Foldable` class. It is currently implemented with `(>>)`, but it could be implemented with `(<*)` or just as `mapM_ = traverse_`. This is desired as well (see the most recent message in the libraries thread at the time of this comment). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 15:06:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 15:06:28 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.18dc2e44ff904c735788f1c78e152fa9@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by acowley): FWIW, I bump into the 62 limit a lot, so 8 would be a real nuisance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 16:44:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 16:44:58 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.b750a74f4abc07738e9fa4251800c054@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | ffi/should_run/7170 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 17:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 17:25:26 -0000 Subject: [GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT In-Reply-To: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> References: <045.c0ad50aa64a5e547bc5ed181d44727f8@haskell.org> Message-ID: <060.8ba5d7491246ff55e2af01a6207b2ff2@haskell.org> #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"640fe14255706ab9c6a1fa101d9b05dfabdc6556/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="640fe14255706ab9c6a1fa101d9b05dfabdc6556" Remove unnecessary loadInterface for TH quoted name. Summary: The load was introduced a32d3e4da0aceb624c958f02cad7327e17ac94db to fix a bug where deprecations assumed that the name in question had already had their interface loaded. The new deprecation code no longer makes this assumption and just loads the interface, so this eager load is not necessary. Verified that TH_reifyType2 continues to work. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D891 GHC Trac Issues: #10419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 18:37:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 18:37:49 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter In-Reply-To: <047.dfa917e245584a02acef03b6e546904f@haskell.org> References: <047.dfa917e245584a02acef03b6e546904f@haskell.org> Message-ID: <062.5b089e28e0bc4971edef7ccb85ed6623@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D920 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D920 * milestone: => 7.12.1 Comment: Easy indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 20:17:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 20:17:38 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.f1cb4a39a2624cf03f715caae8ba4dfd@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Comment (by atnnn): What is the status of this feature? I ran into another case where it might be useful: {{{#!hs {-# LANGUAGE FunctionalDependencies, FlexibleInstances, UndecidableInstances, ConstraintKinds, GADTs #-} class F a | -> a instance (eq ~ (a ~ ()), eq) => F a }}} GHC considers this illegal, but in practice it satisfies the functional dependency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:08:48 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.90846c6870bfb6f22a8271ee890c23f0@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mfdyck.google): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:18:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:18:25 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.44bc81343182952853ba726bfa56e0da@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mfdyck.google): * cc: mfdyck@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:20:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:20:05 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.60d06493d458c816a2c8bd51e39c1c21@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e28462de700240288519a016d0fe44d4360d9ffd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e28462de700240288519a016d0fe44d4360d9ffd" base: fix #10298 & #7695 Summary: This applies a patch from Reid Barton and Sylvain Henry, which fix a disasterous infinite loop when iconv fails to load locale files, as specified in #10298. The fix is a bit of a hack but should be fine - for the actual reasoning behind it, see `Note [Disaster and iconv]` for more info. In addition to this fix, we also patch up the IO Encoding utilities to recognize several variations of the 'ASCII' encoding (including its aliases) directly so that GHC can do conversions without iconv. This allows a static binary to sit in an initramfs. Authored-by: Reid Barton Authored-by: Sylvain Henry Signed-off-by: Austin Seipp Test Plan: Eyeballed it. Reviewers: rwbarton, hvr Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D898 GHC Trac Issues: #10298, #7695 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:20:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:20:05 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.8157955e2a6d1dd88a2f7aa67c5136a1@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e28462de700240288519a016d0fe44d4360d9ffd/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e28462de700240288519a016d0fe44d4360d9ffd" base: fix #10298 & #7695 Summary: This applies a patch from Reid Barton and Sylvain Henry, which fix a disasterous infinite loop when iconv fails to load locale files, as specified in #10298. The fix is a bit of a hack but should be fine - for the actual reasoning behind it, see `Note [Disaster and iconv]` for more info. In addition to this fix, we also patch up the IO Encoding utilities to recognize several variations of the 'ASCII' encoding (including its aliases) directly so that GHC can do conversions without iconv. This allows a static binary to sit in an initramfs. Authored-by: Reid Barton Authored-by: Sylvain Henry Signed-off-by: Austin Seipp Test Plan: Eyeballed it. Reviewers: rwbarton, hvr Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D898 GHC Trac Issues: #10298, #7695 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:25:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:25:04 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.75e7164066077e3df052ced08a693247@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:25:12 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.188fe0258920e44ed6e70505327307fc@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: #7695 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => duplicate * related: => #7695 Comment: Fixed; I'm closing this as a duplicate of #7695, which I'll move to `merge` for 7.10.2. I couldn't unfortunately think of a way to introduce a reliable test here, without chroot/sudo, which is unsuitable for the testsuite. But I can confirm it fixes the above program - in fact, it runs successfully now, thanks to the extra patch from Sylvain, and in the case `iconv` errors, an exception should be thrown properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 21:38:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 21:38:53 -0000 Subject: [GHC] #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler In-Reply-To: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> References: <049.daa8e1241e42497188b789a75fe5ab18@haskell.org> Message-ID: <064.f202bf5eeecd92aa656365c421e3aa2d@haskell.org> #10449: Out-of-tree tests broken on MinGW + native Python due to quoting of config.compiler -------------------------------+------------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Test Suite | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10441 | Differential Revisions: Phab:D911 -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 22:58:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 22:58:25 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.17e01c5170c4f53105fb7b2d03ff1c7a@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, you are right about the cause. * At very least there should be a civilised error message. I'll fix that. * It'd be fine to increase the limit. 62 is also a pretty strange limit, but I think that provided the error message is helpful pretty much any limit is ok, since the workaround (nesting) is very straightforward. For "deriving Eq" we go up to 16-tuples, even though tuples themselves go up to 62, so perhaps 16 would do. * Auto-nesting would be nice, but I think it's probably more pressing for ordinary tuples. I've often thought about doing so, but it's hard to do consistently. For example, suppose (extreme case) that we only supported pairs. Then if someone wrote {{{ f (x,y,z) = e }}} we'd nest the pair so that the "real" type of `f` is `(Int, (Int,Int)) -> blah`. But that would be a confusing type to display. And it would be hard to stop you applying `f` to a nested tuple, e.g. `f (1, (2,3))`. GHC doesn't have a notion of a "user type" and an "implementation type". It's never been pressing enough to jump into this particular swamp. Concretely I propose: * Increase the max arity to 16 * Give a civilised error message if you exceed it * Document the limit acowley: can you explain more about ''how'' you bump up against the 62 limit. Do you really write such large tuples by hand? Or does some program write them? In which case, is nesting difficult? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 23:04:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 23:04:00 -0000 Subject: [GHC] #10444: Tex.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.ad22f9045e1dd7aa74e20c02a19c577a@haskell.org> #10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 28 23:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 May 2015 23:40:52 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.52571f392fd17e0563a1cdd36f18d378@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by acowley): I ran into this with constraints. A [http://www.seas.upenn.edu/~acowley/papers/hocl.pdf paper] I submitted to Haskell Symposium describes a method of factoring an embedded language into various features. In the current state of things, a language that I use for writing GPU programs is defined like this: {{{#!hs type Hocl c repr = (Abstraction c repr, ArrayFeatures c repr, Bitwise c repr, Boolean c repr, Branch c repr, Comp c repr, Cast c repr, Gather c repr, Image c repr, ImageM c repr, Iteration c repr, IterationM c repr, Math c repr, Statements c repr, Swizzle c repr) }}} I've already done some nesting for `Math` and `ArrayFeatures`, and I can do more, so this isn't a deal breaker for me but a matter of convenience. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 01:12:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 01:12:04 -0000 Subject: [GHC] #10399: ApiAnnotations tweaks In-Reply-To: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> References: <044.0c3f894f0badff32a5bc34bfaa09a169@haskell.org> Message-ID: <059.fddbe581680d8c998256b18ca4edfadc@haskell.org> #10399: ApiAnnotations tweaks -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D901 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 01:12:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 01:12:35 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.230b406fa87de93ba11c7f499aee1b0c@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: Phab:D898 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 02:05:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 02:05:29 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.c41982fed2bc8b7d58721a6e08318a7a@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * os: Unknown/Multiple => Windows Comment: I can't reproduce this on Linux (but I can on Windows), reclassifying as a Windows bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 06:01:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 06:01:51 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.076fe12cfd58950d34b4f60b7c401381@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 06:48:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 06:48:22 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required Message-ID: <046.318589501785c7d424a25275b1b3f56a@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: fsimple- | Operating System: Linux tick-factor | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord8_$cpokeByteOff{v rsA} [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: 10400 }}} -fsimple-tick-factor=115 was required See the 'css' branch of https://github.com/mikehat/blaze-markup.git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 07:59:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 07:59:05 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.d2464ead99f8ab819aaf025b6a2bafd7@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D924 Comment: here's a first attempt at a patch; please review if that's the change you suggest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 12:35:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 12:35:51 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.51b3d99381208b5b99c30ee1ff2e5ff9@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 14:16:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 14:16:41 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.59b2f4bd54b2210a0257e3121c80c8ed@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D924 -------------------------------------+------------------------------------- Comment (by ekmett): Looks right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 18:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 18:10:59 -0000 Subject: [GHC] #10459: -fsimple-tick-factor required In-Reply-To: <046.318589501785c7d424a25275b1b3f56a@haskell.org> References: <046.318589501785c7d424a25275b1b3f56a@haskell.org> Message-ID: <061.02cc6a616b4e88197de5491be4b5c819@haskell.org> #10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: fsimple- Operating System: Linux | tick-factor Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Henk-Jan): I got almost the same message when compiling package SFML: ~~~~ [34 of 72] Compiling SFML.Graphics.Transform ( dist\dist-sandbox- 12e87adf\build\SFML\Graphics\Transform.hs, dist\dist-sandbox- 12e87adf\build\SFML\Graphics\Transform.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.1 for i386-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone $j_s8N2 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: 380264 ~~~~ Setting -fsimpl-tick-factor=20000000 did not help. I am using GHC 7.10.1 on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 19:07:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 19:07:04 -0000 Subject: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters In-Reply-To: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> References: <043.7207ef363a1d98123424aaa571c817fa@haskell.org> Message-ID: <058.34d892a2080d82aa91fcb2e620883b95@haskell.org> #6037: Compile-time crash with sources with non-representable unicode characters -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T6037 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 20:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 20:48:10 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.ff6f853d63d6c0ac8eb14fa30fb3d7f1@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: Oops! A possible workaround is to manually define an operator that gives nested pairs of constraints, like this: {{{ type (x :: Constraint) :* (y :: Constraint) = (x, y) type ManyEq2 a = Eq a :* Eq a :* Eq a :* Eq a :* Eq a :* Eq a :* Eq a :* Eq a :* Eq a }}} Alternatively, a type family can be used to expand a list of constraints into nested pairs: {{{ type family All (xs :: [Constraint]) :: Constraint where All '[] = () All (c ': cs) = (c, All cs) type ManyEq3 a = All '[Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 20:59:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 20:59:30 -0000 Subject: [GHC] #10451: Constraint tuple regression in HEAD In-Reply-To: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> References: <046.1b60f916378e7cb70b8878009f7f09f0@haskell.org> Message-ID: <061.c38f3c2a10a7c16037ba895433dc0744@haskell.org> #10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by acowley): The same code base I referred to earlier uses the `All` construction as well (in the initial encoding used for optimization passes). It runs into the context stack limit. Swings and roundabouts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 21:14:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 21:14:22 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any Message-ID: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Presently, we have {{{ {-# LANGUAGE GHCForeignImportPrim #-} module Serum where import GHC.Exts foreign import prim "chenycopy" cheneycopy :: Any -> Any }}} induces the error {{{ Serum.hs:5:1: Unacceptable result type in foreign declaration: ?Any? cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static chenycopy" cheneycopy :: Any -> Any }}} We ought to allow a lifted value to be returned from a foreign primop; no reason not to, anyway; no reason not to, and there are plenty of built-in primops which do this. For reference, lifted arguments were allowed in arugments in this commit: {{{ commit e29001c9e0f73885c0b85d86c3a854519448013a Author: Joachim Breitner Mon Mar 12 01:20:12 2012 Committer: Simon Marlow Wed Mar 14 06:01:18 2012 Allow Any as an argument type to foreign prim functions }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 21:15:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 21:15:21 -0000 Subject: [GHC] #10460: Allow foreign prim to return Any In-Reply-To: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> References: <045.d452fd5027dbbbf0577efe5c37f36bfd@haskell.org> Message-ID: <060.0c6cdd8ea3243e1fe408c4b24449b70d@haskell.org> #10460: Allow foreign prim to return Any -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Old description: > Presently, we have > > {{{ > {-# LANGUAGE GHCForeignImportPrim #-} > module Serum where > import GHC.Exts > > foreign import prim "chenycopy" cheneycopy :: Any -> Any > }}} > > induces the error > > {{{ > Serum.hs:5:1: > Unacceptable result type in foreign declaration: > ?Any? cannot be marshalled in a foreign call > When checking declaration: > foreign import prim safe "static chenycopy" cheneycopy > :: Any -> Any > }}} > > We ought to allow a lifted value to be returned from a foreign primop; no > reason not to, anyway; no reason not to, and there are plenty of built-in > primops which do this. > > For reference, lifted arguments were allowed in arugments in this commit: > > {{{ > commit e29001c9e0f73885c0b85d86c3a854519448013a > Author: Joachim Breitner Mon Mar 12 01:20:12 > 2012 > Committer: Simon Marlow Wed Mar 14 06:01:18 > 2012 > > Allow Any as an argument type to foreign prim functions > }}} New description: Presently, we have {{{ {-# LANGUAGE GHCForeignImportPrim #-} module Serum where import GHC.Exts foreign import prim "chenycopy" cheneycopy :: Any -> Any }}} induces the error {{{ Serum.hs:5:1: Unacceptable result type in foreign declaration: ?Any? cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static chenycopy" cheneycopy :: Any -> Any }}} We ought to allow a lifted value to be returned from a foreign primop; no reason not to, anyway; no reason not to, and there are plenty of built-in primops which do this. For reference, lifted arguments were allowed in arugments in this commit: {{{ commit e29001c9e0f73885c0b85d86c3a854519448013a Author: Joachim Breitner Mon Mar 12 01:20:12 2012 Committer: Simon Marlow Wed Mar 14 06:01:18 2012 Allow Any as an argument type to foreign prim functions }}} I can volunteer to write the patch but it would be good if someone else OKs this before I proceed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 21:21:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 21:21:53 -0000 Subject: [GHC] #10461: Suggest UnliftedFFITypes when applicable Message-ID: <045.902aa16bd3530734a7de01d015325c99@haskell.org> #10461: Suggest UnliftedFFITypes when applicable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Here's an example bad error message: {{{ Serum.hs:5:1: Unacceptable result type in foreign declaration: ?Word#? cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static chenycopy" cheneycopy :: Any -> Word# }}} We should also add something like: {{{ To enable marshalling unlifted types, enable -XUnliftedFFITypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 21:32:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 21:32:05 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.693202ac79014263c65202253ac74559@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Kludgy): NTFS modified dates on Windows are unreliable, often clocking the directory modified date a few seconds ahead or behind their file changes. The results also vary depending on how NTFS is configured. It is likely that Windows users seeing this issue persist after a recache have millisecond precision enabled on timestamps, making ghc-pkg much more sensitive to the errors. Having ghc-pkg work on per-minute precision could help to ameliorate the problem, but ideally the tools should not be relying on implicit assumptions about directory modified times at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 29 21:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 May 2015 21:33:34 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports Message-ID: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here are two issues with our GHCi support for foreign prim imports: Here is a program that works: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #) }}} If I remove the world token passing, as in here: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> Word# }}} I get: {{{ (GHC version 7.10.1 for x86_64-unknown-linux): ByteCodeGen.generateCCall: missing or invalid World token? }}} Another error is if I try to pass Any as an argument: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #) }}} Then I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): primRepToFFIType }}} Note to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 00:27:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 00:27:22 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.fe1e0b9167385acc82974f70174d3ef2@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Changes (by thomie): * owner: Rufflewind => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 00:31:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 00:31:28 -0000 Subject: [GHC] #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself In-Reply-To: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> References: <049.61f3d3a5528377e9b91a5702a2f7acf2@haskell.org> Message-ID: <064.38ed5ca9e66cc6fd21daf481611ef2aa@haskell.org> #10126: Test framework should not assume that GHC tools are in the same directory as GHC itself -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 7.10.2 Component: Test Suite | Version: 7.8.4 Resolution: | Keywords: test Operating System: Unknown/Multiple | framework makefile Type of failure: Other | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D705 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: 7.12.1 => 7.10.2 Comment: This commit is also needed to make the two in #10449 function properly. That changes the test failures in `perf/haddock` from: {{{ 3 had missing libraries }}} To the correct (on my local devel2 build): {{{ 3 unexpected stat failures ... . haddock.Cabal [stat not good enough] (normal) . haddock.base [stat not good enough] (normal) . haddock.compiler [stat not good enough] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 04:51:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 04:51:01 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.cd4f40b172e0077800f112d66c9e3f34@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by a.ulrich): * cc: a.ulrich (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 09:42:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 09:42:57 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.c0a7b0bf1cbb59058170f1a20024849b@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: trommler Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Resolution: | Keywords: Debian Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler Comment: Replying to [comment:7 thomie]: > You're right! > > curl's cabal file would still contain `extra-libraries: curl`. But when installing curl, whoever decides the parameters for the ghc-pkg file (either cabal or ghc, I don't know at the moment) could ask the linker which version it actually found, and write `extra-libraries: :libcurl.so.` to the ghc-pkg file. I think it is sufficient for GHCi to link against `libHScurl.so` (the Haskell library) and omit `-lcurl` (the C library) from the `ld` command altogether. This would make the linking of dynamic libraries way more efficient as fewer shared libraries need to be opened and fewer symbol tables need to be read. See p 41 of Ulrich Drepper's "How To Write Shared Libraries" http://www.akkadia.org/drepper/dsohowto.pdf. I am going to look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 13:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 13:47:06 -0000 Subject: [GHC] #10463: Wrong warning with PartialTypeSignatures Message-ID: <047.c9ed6af0d80ddd0588b394ac97106388@haskell.org> #10463: Wrong warning with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This program {{{#!hs {-# LANGUAGE ScopedTypeVariables, PartialTypeSignatures #-} f (x :: _) = x ++ "" }}} gives this warning {{{ Bug.hs:2:9: Warning: Found hole ?_? with type: [Char] Relevant bindings include f :: [Char] -> [Char] (bound at Bug.hs:2:1) In a pattern type signature: _ In the pattern: x :: _ In an equation for ?f?: f (x :: _) = x ++ "" }}} But there is no hole, only an _ in a type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 14:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 14:41:56 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm Message-ID: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> #10464: ghc 7.8.4 on arm -------------------------------------+------------------------------------- Reporter: | Owner: andrewufrank | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Compile-time Architecture: arm | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- when compiling i get the warning /usr/bin/d.gold: warning: cannot scan executable section 1 of ..... transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping symbols. there are some informations on the web on the cortex-a8 erratum, but i cannot see how i could apply them. should the compiler be recompiled? i installed from the debian distribution. the hardware is a cubietruck. i observe that compilation, especially the phase of preparing the configuration in cabal takes very long - perhaps this is related to this problem. the resulting code is ok and runs with expected speed. thank you for producing a full ghc for arm! andrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 15:08:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 15:08:19 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter In-Reply-To: <047.dfa917e245584a02acef03b6e546904f@haskell.org> References: <047.dfa917e245584a02acef03b6e546904f@haskell.org> Message-ID: <062.4fb1a05c13aa4afc981e8cd6f8b666f7@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D920 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"508a3a33988d2872f580d8b727036f7f443d8b6d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="508a3a33988d2872f580d8b727036f7f443d8b6d" Build system: don't build runghc if GhcWithInterpreter=NO (#10261) To test: * run `make clean` in utils/runghc * make sure inplace/bin doesn't contain runghc * set GhcWithInterpreter=NO in build.mk * run `make` * note that inplace/bin doesn't contain runghc It won't be installed either, nor will runhaskell. Differential Revision: https://phabricator.haskell.org/D920 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 15:17:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 15:17:24 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter In-Reply-To: <047.dfa917e245584a02acef03b6e546904f@haskell.org> References: <047.dfa917e245584a02acef03b6e546904f@haskell.org> Message-ID: <062.e2def69711230252fa1358fdb83c8398@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D920 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 15:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 15:22:46 -0000 Subject: [GHC] #10465: Make listArray non-strict in structure of argument list Message-ID: <043.a3cf2e854a0ba1028093fcd722d6605d@haskell.org> #10465: Make listArray non-strict in structure of argument list -------------------------------------+------------------------------------- Reporter: atze | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Runtime crash Keywords: laziness | Blocked By: array | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There is a subtle caveat when using Data.Array.IArray.listArray, which could be easily avoided. The problem is that listArray strict in the structure of the list, and hence if this structure depends on the result of listArray, then the result is undefined. However, listArray does not have to be strict in the structure of the list. As an example, consider computing the "failure function" for the Knuth- Morris-Pratt algorithm: {{{#!hs failureFunc :: Eq a => Array Int a -> Array Int Int failureFunc string = result where result = listArray (bounds string) (-1 : 0 : getMatch 2 0) getMatch :: Int -> Int -> [Int] getMatch p matchPos | matchPos < 0 = 0 : getMatch (p+1) 0 | string ! (p - 1) == string ! matchPos = matchPos + 1 : getMatch (p+1) (matchPos+1) | otherwise = getMatch p (result ! matchPos) -- use result! }}} This seems reasonable, we just use the result of elements < i to construct element i. However, it does not work: {{{#!hs Main> elems $ failureFunc (listArray (0,23) "participate in parachute") *** Exception: <> }}} The problem is that listArray is equivalent to: {{{#!hs listArray b l = array b (zip (range b) l) }}} (Recall that array is strict in the structure of the given list, and in the first elements of the tuples in this list, but not in the elements.) The structure of the list l=(-1 : 0 : getMatch 2 0) depends on the observing elements of the array (result ! matchPos). The structure of (zip (range b) l) is strict in the structure of l, and hence failure loops. Proposed solution: redefine listArray as equivalent to: {{{#!hs listArray b l = array b (zipLazyRight (range b) l) zipLazyRight :: [a] -> [b] -> [(a,b)] zipLazyRight [] _ = [] zipLazyRight (h:t) l = (h,head l): zipLazyRight t (tail l) }}} The difference is that listArray is now non-strict in the structure of the argument list, because zipLazyRight is non-strict in the right argument. Using this definition, failureFunc does not fail: {{{#!hs Main> elems $ failureFuncArr (toArr "participate in parachute") [-1,0,0,0,0,0,0,0,1,2,0,0,0,0,0,0,1,2,3,0,0,0,0,0] }}} This does not change the semantics uses of listArray which were already defined: it just makes more uses of listArray defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 15:28:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 15:28:48 -0000 Subject: [GHC] #10465: Make listArray non-strict in structure of argument list In-Reply-To: <043.a3cf2e854a0ba1028093fcd722d6605d@haskell.org> References: <043.a3cf2e854a0ba1028093fcd722d6605d@haskell.org> Message-ID: <058.560147e329f3d79a99a30c9b936d2ffd@haskell.org> #10465: Make listArray non-strict in structure of argument list -------------------------------------+------------------------------------- Reporter: atze | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: laziness Operating System: Unknown/Multiple | array Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by atze: Old description: > There is a subtle caveat when using Data.Array.IArray.listArray, which > could be easily avoided. > > The problem is that listArray strict in the structure of the list, and > hence if this structure depends on the result of listArray, then the > result is undefined. However, listArray does not have to be strict in the > structure of the list. > > As an example, consider computing the "failure function" for the Knuth- > Morris-Pratt algorithm: > > {{{#!hs > failureFunc :: Eq a => Array Int a -> Array Int Int > failureFunc string = result where > result = listArray (bounds string) (-1 : 0 : getMatch 2 0) > getMatch :: Int -> Int -> [Int] > getMatch p matchPos > | matchPos < 0 = 0 : getMatch (p+1) 0 > | string ! (p - 1) == string ! matchPos = matchPos + 1 : getMatch > (p+1) (matchPos+1) > | otherwise = getMatch p (result ! matchPos) -- use result! > }}} > > This seems reasonable, we just use the result of elements < i to > construct element i. However, it does not work: > > {{{#!hs > Main> elems $ failureFunc (listArray (0,23) "participate in parachute") > *** Exception: <> > }}} > The problem is that listArray is equivalent to: > {{{#!hs > listArray b l = array b (zip (range b) l) > }}} > (Recall that array is strict in the structure of the given list, and in > the first elements of the tuples in this list, but not in the elements.) > > The structure of the list l=(-1 : 0 : getMatch 2 0) depends on the > observing elements of the array (result ! matchPos). The structure of > (zip (range b) l) is strict in the structure of l, and hence failure > loops. > > Proposed solution: redefine listArray as equivalent to: > {{{#!hs > listArray b l = array b (zipLazyRight (range b) l) > > zipLazyRight :: [a] -> [b] -> [(a,b)] > zipLazyRight [] _ = [] > zipLazyRight (h:t) l = (h,head l): zipLazyRight t (tail l) > }}} > > The difference is that listArray is now non-strict in the structure of > the argument list, because zipLazyRight is non-strict in the right > argument. Using this definition, failureFunc does not fail: > {{{#!hs > Main> elems $ failureFuncArr (toArr "participate in parachute") > [-1,0,0,0,0,0,0,0,1,2,0,0,0,0,0,0,1,2,3,0,0,0,0,0] > }}} > This does not change the semantics uses of listArray which were already > defined: it just makes more uses of listArray defined. New description: There is a subtle caveat when using Data.Array.IArray.listArray, which could be easily avoided. The problem is that listArray strict in the structure of the list, and hence if this structure depends on the result of listArray, then the result is undefined. However, listArray does not have to be strict in the structure of the list. As an example, consider computing the "failure function" for the Knuth- Morris-Pratt algorithm: {{{#!hs failureFunc :: Eq a => Array Int a -> Array Int Int failureFunc string = result where result = listArray (bounds string) (-1 : 0 : getMatch 2 0) getMatch :: Int -> Int -> [Int] getMatch p matchPos | matchPos < 0 = 0 : getMatch (p+1) 0 | string ! (p - 1) == string ! matchPos = matchPos + 1 : getMatch (p+1) (matchPos+1) | otherwise = getMatch p (result ! matchPos) -- use result! }}} This seems reasonable, we just use the result of elements < i to construct element i. However, it does not work: {{{#!hs Main> elems $ failureFunc (listArray (0,23) "participate in parachute") *** Exception: <> }}} The problem is that listArray is equivalent to: {{{#!hs listArray b l = array b (zip (range b) l) }}} (Recall that array is strict in the structure of the given list, and in the first elements of the tuples in this list, but not in the second elements of the tuples.) The structure of the list l=(-1 : 0 : getMatch 2 0) depends on the observing elements of the array (result ! matchPos). The structure of (zip (range b) l) is strict in the structure of l, and hence failure loops. Proposed solution: redefine listArray as equivalent to: {{{#!hs listArray b l = array b (zipLazyRight (range b) l) zipLazyRight :: [a] -> [b] -> [(a,b)] zipLazyRight [] _ = [] zipLazyRight (h:t) l = (h,head l): zipLazyRight t (tail l) }}} The difference is that listArray is now non-strict in the structure of the argument list, because zipLazyRight is non-strict in the right argument. Using this definition, failureFunc does not fail: {{{#!hs Main> elems $ failureFuncArr (toArr "participate in parachute") [-1,0,0,0,0,0,0,0,1,2,0,0,0,0,0,0,1,2,3,0,0,0,0,0] }}} This does not change the semantics uses of listArray which were already defined: it just makes more uses of listArray defined. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 19:50:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 19:50:51 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.0deabde9e264c6186ab052bcd54541a7@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by archblob): * owner: => archblob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 19:53:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 19:53:06 -0000 Subject: [GHC] #10101: ghci :e throws exception after type error In-Reply-To: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> References: <047.4e10f5b4ba34fdb5edb05b220d58e9f5@haskell.org> Message-ID: <062.cc96be3aad5bf9bfc63685173d0bf28b@haskell.org> #10101: ghci :e throws exception after type error -------------------------------------+------------------------------------- Reporter: diatchki | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D930 -------------------------------------+------------------------------------- Changes (by archblob): * differential: => Phab:D930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 21:13:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 21:13:29 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.481db90d027b7bbd596ead153e857885@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 30 21:37:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 May 2015 21:37:43 -0000 Subject: [GHC] #10466: Bogus multiple-declaration error in GHCi + Template Haskell Message-ID: <046.d8399315d1063d9ff461c2d68cee54f0@haskell.org> #10466: Bogus multiple-declaration error in GHCi + Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Try this (with ghc 7.8.3) {{{ th% ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 th $ ghc --interactive -XTemplateHaskell GHCi, version 7.8.3: 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> let x = True Prelude> let y = [d| x = 'c' |] :3:13: Multiple declarations of ?x? Declared at: :2:5 :3:13 In the Template Haskell quotation [d| x = 'c' |] }}} This is obviously wrong, a failure of the name-shadwing code in `RnNames.extendGlobalRdrEnvRn`. I suspect that this afflicts 7.10 too, but I can't check that right now. Working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 01:44:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 01:44:16 -0000 Subject: [GHC] #10467: user's guide description of "foreign export" is out of date Message-ID: <047.ce62d536f877089b14fe11348144e797@haskell.org> #10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The first sentence of section 8.2.1 is > When GHC compiles a module (say M.hs) which uses foreign export or foreign import "wrapper", it generates two additional files, M_stub.c and M_stub.h. GHC will automatically compile M_stub.c to generate M_stub.o at the same time. This is false at least for registerised builds, GHC produces an object file directly and its filename is `M.o` not `M_stub.o`. (I don't know what happens in the unregisterised case, but if the final object file name is actually different, that seems inconsistent.) The rest of the section makes similar references to the nonexistent `M_stub.c` and `M_stub.o`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 05:27:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 05:27:43 -0000 Subject: [GHC] #8292: linker_unload test doesn't work on Windows In-Reply-To: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> References: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> Message-ID: <060.8eb8daff51e6b4d36f080ef0150bfdd4@haskell.org> #8292: linker_unload test doesn't work on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | linker_unload | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: simonmar => ezyang Comment: It does work now! I'll push a commit marking this as passing when I can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 05:31:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 05:31:34 -0000 Subject: [GHC] #10468: debug test case fails on Windows Message-ID: <045.b19678979c06629a2acceac03a72cd6b@haskell.org> #10468: debug test case fails on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Debugging) | Operating System: Windows Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: debug | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Here's the make output: {{{ $ make debug # Without optimisations, we should get annotations for basically # all expressions in the example program. echo == Dbg == == Dbg == 'C:/msys64/home/ezyang/ghc-validate/inplace/bin/ghc-stage2.exe' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs debug -fforce-recomp -g -dppr-ticks -ddump-cmm \ | grep -o src\ | sort -u C:\msys64\tmp\ghc21036_0\ghc21036_2.s: Assembler messages: C:\msys64\tmp\ghc21036_0\ghc21036_2.s:421: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:508: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:557: Error: junk at end of line, first unrecognized character is `,' C:\msys64\tmp\ghc21036_0\ghc21036_2.s:559: Error: junk at end of line, first unrecognized character is `,' src src src src src src src src src src src ./debug make: ./debug: Command not found Makefile:9: recipe for target 'debug' failed make: *** [debug] Error 127 }}} Peter, can you take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 06:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 06:14:01 -0000 Subject: [GHC] #8292: linker_unload test doesn't work on Windows In-Reply-To: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> References: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> Message-ID: <060.457d5aec3dfe8f38157413a87ef82948@haskell.org> #8292: linker_unload test doesn't work on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | linker_unload | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"7db2dec2cf4fae68f7bb490d7c7780288350b597/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7db2dec2cf4fae68f7bb490d7c7780288350b597" linker_unload working on Windows, fixes #8292. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 06:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 06:14:01 -0000 Subject: [GHC] #9930: By default, a source code without extension would get overwritten by executable on *nix In-Reply-To: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> References: <049.ce546f2e46260ffee3d03a0558c425a6@haskell.org> Message-ID: <064.a97f74cd5997ebed8f0682829983888b@haskell.org> #9930: By default, a source code without extension would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Rufflewind Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5a65da43559908a42a701b4dbdff682dcdf2e121/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a65da43559908a42a701b4dbdff682dcdf2e121" Don't run T9330fail on Windows, no clobber occurs. #9930 Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 06:15:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 06:15:42 -0000 Subject: [GHC] #8292: linker_unload test doesn't work on Windows In-Reply-To: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> References: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> Message-ID: <060.3262ef421703afa046425dde8ce3d073@haskell.org> #8292: linker_unload test doesn't work on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | linker_unload | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 11:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 11:24:31 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.775b5d77e7e86c3f062c5062441ecc8d@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D931 -------------------------------------+------------------------------------- Changes (by mlen): * status: new => patch * differential: => D931 Comment: Sorry for the long delay. Finally I found some time (during ZuriHac) to rework the patch to include tests that the code is really generated and created the differential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 11:29:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 11:29:41 -0000 Subject: [GHC] #10452: ApiAnnotations : rationalise tests In-Reply-To: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> References: <044.92365aad7d7f8e3dca664006b00e42b6@haskell.org> Message-ID: <059.1ad34189d48b34ac93ceaa0e88e46701@haskell.org> #10452: ApiAnnotations : rationalise tests -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 11:34:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 11:34:34 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.46c7f2221dec836663b8043dd31a5029@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D931 -------------------------------------+------------------------------------- Changes (by nomeata): * differential: D931 => Phab:D931 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 12:22:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 12:22:53 -0000 Subject: [GHC] #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings In-Reply-To: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> References: <049.41b7d0833f2869d11544c1b4baf6f0c5@haskell.org> Message-ID: <064.10479398e9bc5e7497f63dfff95d0b06@haskell.org> #10438: GHC 7.10.1 panic due to PartialTypeSignatures, TypeFamilies, and local bindings -------------------------------------+------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by archblob): This does no longer reproduce on current HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 12:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 12:30:54 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist In-Reply-To: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> References: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> Message-ID: <057.881353c893953a65e8c1f983b669067f@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by archblob): You can find more details about why thing are the way they are and how to force recompilation in the [[https://downloads.haskell.org/~ghc/7.0-latest/docs/html/users_guide /separate-compilation.html#recomp | user guide]] Maybe change this to a feature request ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 12:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 12:39:32 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist In-Reply-To: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> References: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> Message-ID: <057.887e3c508b5cb5234795c5536f596001@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by archblob): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 13:14:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 13:14:33 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.42e1235be6f6bf99c14ffab28c1a76aa@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Keywords: dwarf Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D792 Related Tickets: | -------------------------------------+------------------------------------- Comment (by tibbe): Could we have a test for this so it doesn't break in the future? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 14:32:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 14:32:45 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.8f5532d5ee556fe3a3fc22cfadc7cb9a@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dreixel): I agree that this is a bug, yes. Not entirely sure when I will have time to fix it, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 15:07:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 15:07:40 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist In-Reply-To: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> References: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> Message-ID: <057.448313e378dfe40bcb6b17379f2d66fb@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * status: new => closed * resolution: => invalid Comment: The documentation pointed out in comment:3 is clear. Thanks! I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 15:41:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 15:41:04 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.55eb1597f231407fec82c4a5e61d0934@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5666 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 18:08:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 18:08:21 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type Message-ID: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type -----------------------------------+--------------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240 (GHC version 7.10.1 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any "Compiling" lines, or within the first 1 or 2 files compiled. I got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash. The hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103. I was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem. Happy to debug further, although this machine is a bit resource constrained to do things like building ghc on it. ghc 7.8.4 and 7.10.1 both crash the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 31 20:32:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 May 2015 20:32:03 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.3eb7b97601bede031a0dd8b21a1a0e51@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: 5321 | -------------------------------------+------------------------------------- Comment (by archblob): These are times measured on an i3-2100 CPU @ 3.10GHz running Ubuntu 15.04 and GHC 7.10.1 : ||= input =||= real =|| ||200 a a || 0m0.609s || ||300 a a || 0m0.689s || ||400 a a || 0m0.884s || ||500 a a || 0m0.942s || ||200 b a || 0m2.028s || ||200 c a || 0m1.092s || ||10000 a d || 0m1.978s || They are grately improved and needed no stack adjustment. Tail-recursive variant is still a lot slower. -- Ticket URL: GHC The Glasgow Haskell Compiler