From ghc-devs at haskell.org Sat Feb 1 00:02:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 00:02:53 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.3b0d60344930c35a547e5c1c5b677f4e@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): The relevant code is in `compiler/ghci/Linker.lhs`, functions `linkDependencies`, `getLinkDeps`, `dynLinkObjs` and `dynLoadObjs`. When linking in a module GHC attempts to link ''all the object files that are not already loaded into GHC'' into a single shared library and then dlopen that library. That fails here because `T8696B.o` apparently contains a PC- relative relocation to `T8696A.o` and therefore cannot be dynamically linked to it. I noticed that both `getLinkDeps` and `dynLinkObjs` seem to be guilty of pruning modules/object files that have already been loaded into GHC from the list of dependencies to link together. But even if they did not prune any dependencies, would there then be problems with two copies of `T8696A.o` being loaded into GHC? So I'm not sure what the right fix is here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 00:11:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 00:11:35 -0000 Subject: [GHC] #8723: sdist should not have to build everything Message-ID: <046.92216f47e2ba2986f6ec19c3e526b45f@haskell.org> #8723: sdist should not have to build everything ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It would be nice if instead of {{{ $ perl boot $ ./configure $ make $ make sdist }}} it would suffice to run {{{ $ perl boot $ ./configure $ make sdist }}} and if that would not build more than necessary to generate the tarballs. It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on. I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-)) Remember to update MakingReleases and Building/StandardTargets if this is implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 07:28:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 07:28:31 -0000 Subject: [GHC] #8724: CAS and Xchange in SMP.h don't use quadword instructions on x86_64 systems Message-ID: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> #8724: CAS and Xchange in SMP.h don't use quadword instructions on x86_64 systems ----------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Ryan Newton pointed out on the mailing list that CAS wasn't behaving correctly in his heavy concurrency benchmarks. http://www.haskell.org/pipermail/ghc-devs/2014-February/003944.html upon looking at the inline ASM, it looks like both CAS and Xchng were probably using the 32bit versions of their asm operations, or at least thats my strawman interpretation. https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...fix_64bit_intel_cas is the patch, which should be tested and confirmed to resolve this issue before getting merged in. This patch makes the 64 bit versions of CAS and xchg use the quad word instructions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 07:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 07:46:34 -0000 Subject: [GHC] #8724: unexpected CAS failures (was: CAS and Xchange in SMP.h don't use quadword instructions on x86_64 systems) In-Reply-To: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> References: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> Message-ID: <060.1775f2116e50b49648aa81b3cc97c174@haskell.org> #8724: unexpected CAS failures -------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by carter): * priority: highest => normal Comment: ok, looking at example gcc code, it appears that this patch doesn't change the code generated, so the bug understanding is still afoot. Also remains to be seen to understand the bug more -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 08:34:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 08:34:45 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.c0e752c42f17b7e91bf6c6dfe2d9de36@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch Comment: x86 and x86_64 builds are all fine. On powerpc64 I now get #8301 again. Please review the patch and consider merging it into 7.8. PS: I wonder if https://ghc.haskell.org/trac/ghc/changeset/48326cfb1ef4b455f81fbbece7a17dab17f7c932/ghc is still needed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 10:19:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 10:19:02 -0000 Subject: [GHC] #8720: ghc crash In-Reply-To: <044.f80d33b8a7200bf29e1b5ccf24b38d5f@haskell.org> References: <044.f80d33b8a7200bf29e1b5ccf24b38d5f@haskell.org> Message-ID: <059.e7263c38428cfbc7c8bdcf10e2e25a88@haskell.org> #8720: ghc crash --------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Keywords: ghci crash mvar thread block Resolution: | Architecture: x86_64 (amd64) invalid | Difficulty: Unknown Operating System: | Blocked By: Windows | Related Tickets: Type of failure: GHCi | crash | Test Case: | Blocking: | --------------------------+------------------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => invalid Comment: I'm afraid with no way to reproduce there's little point in having this ticket. It does look like #4245 which is a common bug (several duplicates). If you find a way, please reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 10:40:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 10:40:10 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken Message-ID: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Hi, when the building the Debian package of GHC HEAD, I get this error: {{{ $ /usr/bin/make DESTDIR=/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp install [...] /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc /old-time-1.1.0.2 "inplace/bin/ghc-cabal" copy libraries/haskell98 dist-install "strip" '/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp' '/usr' '/usr/lib/ghc' '/usr/share/doc/ghc-doc/html/libraries' 'v p dyn' Installing library in /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/haskell98-2.0.0.3 "inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp' '/usr' '/usr/lib/ghc' '/usr/share/doc/ghc-doc/html/libraries' 'v p dyn' Installing library in /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/haskell2010-1.1.1.1 "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin /ghc-pkg" --force --global-package-db "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/package.conf.d" update rts/dist/package.conf.install /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin /ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.0-ghc7.9.20140130.so: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Fehler 127 make: *** [install] Fehler 2 }}} The problem is that it is calling ghc-pkg at the installed position, where it cannot find its libraries. `/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/bin /ghc-pkg` would also not work, as that refers to absolute paths which are not there yet. I guess it should continue using the binaries in `inplace/bin` just like for `ghc-cabal`. But that alone does not help: {{{ "inplace/bin/ghc-pkg" --force --global-package-db "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib/ghc/rts-1.0 doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts- ghc7.9.20140130.so","libHSrts-ghc7.9.20140130.dylib","HSrts- ghc7.9.20140130.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin/ghc" "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin /ghc-pkg" "/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc" '/home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp' '/usr' '/usr/lib/ghc' '/usr/share/doc/ghc-doc/html/libraries' NO Warning: cannot determine version of /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin/ghc : "" Warning: cannot determine version of /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin /ghc-pkg : "" ghc-cabal: /home/nomeata/dailies/2014-01-31/ghc-7.9.20140130/debian/tmp/usr/lib/ghc/lib/bin /ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.0-ghc7.9.20140130.so: cannot open shared object file: No such file or directory }}} It would be nice if this can be fixed before 7.8.1, packagers rely on `DESTDIR`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 10:54:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 10:54:30 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.04d4faa8441919cf2d2e6dc60f351ab6@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Changes (by monoidal): * milestone: 7.6.2 => 7.10.1 Comment: I've updated the patches again - three above files are ready for GHC 7.10. The warning is enabled by default, and the plan is that GHC 7.12 will give an error with implicit quantification on contexts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 11:15:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 11:15:07 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.b1c9567b4cbc61bbdf70f80dfce6b798@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by hvr): Why isn't there an official `libffi-3.0.14.tar.gz` at https://sourceware.org/libffi/? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 11:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 11:24:17 -0000 Subject: [GHC] #8701: Update libffi-tarballs to latest libffi In-Reply-To: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> References: <045.7220d8c135ec272812ad62a34a63cda9@haskell.org> Message-ID: <060.5de8844bc96714acf57bdd550a526e2c@haskell.org> #8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by lukexi): * status: new => closed * resolution: => invalid Comment: Sorry, the filename was poorly chosen; this is a tar.gz of libffi HEAD https://github.com/atgreen/libffi. But it actually doesn't include all the arm patches we need yet anyway :/. I'll close this until we can get a working official release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 11:39:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 11:39:20 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.5b6bf180ef9efaf86cb13fe8fea90fe1@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by monoidal): Here's a simpler version, compiling `-O -dcore-lint` gives an error {{{ {-# LANGUAGE ExistentialQuantification #-} module Main where data HLState = forall a. HLState (a -> a) !a data BufferImpl = FBufferData !HLState focusAst :: BufferImpl -> HLState focusAst (FBufferData (HLState f x)) = HLState f (f x) main = return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 13:37:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 13:37:47 -0000 Subject: [GHC] #8585: Loopification should omit stack check In-Reply-To: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> References: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> Message-ID: <063.f3411ca07b984512b4b69d2f5a31311f@haskell.org> #8585: Loopification should omit stack check --------------------------------------------+------------------------------ Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Jan Stolarek ): In [changeset:"ea584ab634b17b499138bc44dbec777de7357c19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ea584ab634b17b499138bc44dbec777de7357c19" Loopification jump between stack and heap checks Fixes #8585 When emmiting label of a self-recursive tail call (ie. when performing loopification optimization) we emit the loop header label after a stack check but before the heap check. The reason is that tail-recursive functions use constant amount of stack space so we don't need to repeat the check in every loop. But they can grow the heap so heap check must be repeated in every call. See Note [Self-recursive tail calls] and [Self-recursive loop header]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 13:40:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 13:40:32 -0000 Subject: [GHC] #8585: Loopification should omit stack check In-Reply-To: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> References: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> Message-ID: <063.3bfb97eac025efaa155d63943943a193@haskell.org> #8585: Loopification should omit stack check --------------------------------------------+------------------------------ Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 16:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 16:52:02 -0000 Subject: [GHC] #8724: unexpected CAS failures In-Reply-To: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> References: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> Message-ID: <060.16c0d51796aa4ba54a772b5b35a05e02@haskell.org> #8724: unexpected CAS failures -------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by carter): * status: new => patch Comment: ok so my original reason for my exploratory patching in https://github.com/cartazio/ghc/compare/ghc:ghc-7.8...fix_64bit_intel_cas seems to be wrong, but there is a use of unsigned in where it should be StgWord -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 16:53:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 16:53:05 -0000 Subject: [GHC] #8724: x86_64 cas references unsigned int rather than StgWord (was: unexpected CAS failures) In-Reply-To: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> References: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> Message-ID: <060.316fdee9da822421ae5454230f01c824@haskell.org> #8724: x86_64 cas references unsigned int rather than StgWord -------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 19:24:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 19:24:59 -0000 Subject: [GHC] #8724: x86_64 cas references unsigned int rather than StgWord In-Reply-To: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> References: <045.b0171fcfc84c933870d42a29c9dd33d3@haskell.org> Message-ID: <060.24714cc4b0396657f8abc61c097dc35e@haskell.org> #8724: x86_64 cas references unsigned int rather than StgWord -------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by carter): * status: patch => closed * resolution: => invalid Comment: hrm, looks like ryan's bugs may have been bad cpp (and i can't reproduce the bugs in 7.8 too) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 19:26:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 19:26:37 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.fd17dc2b858ddfbaeae3a9625bb0a352@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:4 simonpj]: > Incidentally, if you want GHC to auto-specialise an '''imported''' function, to types that may not even be in scope in the defining module, you should mark that function as `INLINABLE` I have been playing around with this some more, and found something interesting. As I mentioned, despite the fact that I have everything marked `INLINABLE`, GHC was *not* auto-specializing `plusFastCyc`. However, if I partially apply the call to `plusFastCyc` in Main to `iterate (plusFastCyc y) ...` instead of `iterate (\x -> plusFastCyc y x) ...`, GHC *does* automatically specialize the call to `plusFastCyc`. However, the code is still slow because `(+)` is still not specialized. I might expect (+) to be specialized for two reasons 1. It is called at the top level in Main.hs in the `foldl`. 2. The docs say that *when* there is an explicit pragma, specialization is transitive. I could hope that auto-specialization is also transitive. Is this the case? Is the problem of GHC specializing the partially applied function but not the fully applied version related to ticket:8099? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 19:29:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 19:29:30 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.ef4bfd90b22b684011443ce3b099cb50@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by carter): any function marked inlineable or inline wont get specialize. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 20:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 20:22:00 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.ea183082647fcace4e0aa39ef732a37f@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by crockeea): Replying to [comment:20 carter]: > any function marked inlineable or inline wont get specialize., or at least i seem to recall theres some phase ordering issues related to that. That's in direct contradiction to the docs ("However if a function f is given an INLINABLE pragma at its definition site, then it can subsequently be specialised by importing modules"), and to Simon's comment above. Furthermore, removing "INLINABLE" doesn't help matters. Sure there can be phase issues, but the point is inlining is not occurring at all, so in particular it is not happening in place of specialization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 21:37:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 21:37:46 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.f5faaaef8c26cd0ec419f161d1d5a6bd@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:11 monoidal]: > I've updated the patches again - three above files are ready for GHC 7.10. The patch for hackage:haskeline would have to go via https://github.com/judah/haskeline though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 23:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 23:00:56 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi In-Reply-To: <044.52006547921df8c64442c64892015775@haskell.org> References: <044.52006547921df8c64442c64892015775@haskell.org> Message-ID: <059.9e6aa375de03d885b06a32c2f88bdef6@haskell.org> #8717: Segfault in 64-bit Windows GHCi -------------------------------+---------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Difficult (2-5 days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------------- Comment (by awson): Disregard the whole ticket. It was a weird artifact of #7134. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 23:01:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 23:01:49 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi In-Reply-To: <044.52006547921df8c64442c64892015775@haskell.org> References: <044.52006547921df8c64442c64892015775@haskell.org> Message-ID: <059.d75d426644a039dd37c326392619903f@haskell.org> #8717: Segfault in 64-bit Windows GHCi -------------------------------+---------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Difficult (2-5 days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------------- Changes (by awson): * status: patch => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 23:14:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 23:14:45 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.78ce383c6ad80b0798060eb8587f1319@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Finally ironed out the egregious bug which causes numerical segfaults here and there. The culprit is 4179-4185 lines part (redundant {{{ghciInsertSymbolTable}}}). Other changes are tiny fixes (not particularly important). This also fixes #8717. I've closed it as "invalid" then. Please apply to 7.8 and HEAD. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 1 23:45:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Feb 2014 23:45:11 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.f1a1ac206e52e8aca9f0080fcbd7ed5b@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nomeata): Candidate that might have broken that is 898cb090c8812704448ec4cb1c10d50df4b7d664/ghc by Ian, and most other changes to `ghc.mk` are by Ian. Ian, since you seem to be the expert on the build system, do you think you can fix this easily? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 09:49:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 09:49:09 -0000 Subject: [GHC] #8726: integer-gmp division regression Message-ID: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> #8726: integer-gmp division regression --------------------------+------------------------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 libraries (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Integer | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ With ghc 7.6.3: {{{ ghci> quotRem 0x10000000000000001 (-0x100000) (-17592186044416,1) ghci> quotRem 0x10000001 (-0x100000) (-256,1) }}} with ghc 7.7 {{{ ghci> quotRem 0x10000000000000001 (-0x100000) (-17592186044416,-1) ghci> quotRem 0x10000001 (-0x100000) (-256,1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 09:56:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 09:56:57 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.df9d31c9ada5985cd6c7b88d3f4b444a@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Integer-gmp Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by hvr): * keywords: Integer => Integer-gmp * owner: => hvr * version: 7.7 => 7.8.1-rc1 * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 10:09:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 10:09:09 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.a8e8fa33cbccfa10d3f5bb2f86ef2cc5@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Integer-gmp Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by erikd): Related problems with divMod. ghc-7.6.3: {{{ Prelude> divMod 0x10000000000000001 (-0x100000) (-17592186044417,-1048575) Prelude> divMod 0x10000000001 (-0x100000) (-1048577,-1048575) }}} ghc-7.6: {{{ Prelude> divMod 0x10000000000000001 (-0x100000) (17592186044417,1048575) Prelude> divMod 0x10000000001 (-0x100000) (-1048577,-1048575) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 13:16:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 13:16:58 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.89c6c6488e0ce858d88897437a2c9624@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Integer-gmp Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5f64b2c6e8f1799d7015098598f7d6e826707e6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5f64b2c6e8f1799d7015098598f7d6e826707e6c" Add test-case for #8726 This tests various properties expected to hold for quotRem, divMod, div, mod, quot, and rem. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 13:17:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 13:17:58 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.6ae363d299d2f314e99eb5d378987120@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Integer-gmp Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"2f841fdf5b33c4eb32cfc5d1b8207585f1880d9a/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="2f841fdf5b33c4eb32cfc5d1b8207585f1880d9a" Fix negation of `divMod`/`quotRem` results (fixes #8726) High-level pseudo code of what the code was supposed to implement: quotRem' :: Integer -> Integer -> (Integer,Integer) quotRem' a b@(S# _) | b < 0 = negFst . uncurry quotRem' . negSnd $ (a,b) | otherwise = quotRemUI a (fromIntegral (abs b)) divMod' :: Integer -> Integer -> (Integer,Integer) divMod' a b@(S# _) | b < 0 = negSnd . uncurry divMod' . negBoth $ (a,b) | otherwise = divModUI a (fromIntegral b) negFst (q,r) = (-q,r) negSnd (q,r) = ( q,-r) negBoth (q,r) = (-q,-r) -- quotRemUI and divModUI represent GMP's `mpz_{f,t}div_qr_ui()` quotRemUI, divModUI :: Integer -> Word -> (Integer,Integer) Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 15:45:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 15:45:57 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box Message-ID: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box ----------------------------------+-------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): loadArchive "/home/vagrant/.cabal/lib/x86_64-linux- ghc-7.6.3/HLearn-2.0.0.0/libHSHLearn-2.0.0.0.a": failed {{{ import HLearn.Algebra import Control.DeepSeq import HLearn.Models.Distributions import Statistics.Distribution.Normal dataset = [1,2,3,4,5,6] --dist = train dataset :: Normal Double data Marble = Red | Green | Blue | White deriving (Read,Show,Eq,Ord) simonBag :: [Marble] simonBag = [Red, Red, Red, Green, Blue, Green, Red, Blue, Green, Green, Red, Red, Blue, Red, Red, Red, White] simonDist = train simonBag :: Categorical Double Marble }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 15:47:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 15:47:13 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.9502d015035e3f3ae9ebfcec255bd1c8@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): it works on osx 10.8.5 but trying to run it on a vagrant box it produced this error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 16:33:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 16:33:23 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.3f469b9494c9e600e37a5feca4c79396@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): could you try in a sandbox on the vagrant box? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 17:44:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 17:44:16 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.9a94a8339ec774bc0b622dceb3bd6af4@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): Well I am quite new to haskell and not so familiar with the sanbox logic as the tuto I got didn't help. Do you have a quick "how to do it", I mean should I install cabal-dev and what are the steps after to install HLearn and run ghci from where ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 19:28:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 19:28:56 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal Message-ID: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> #8728: Segmentation fault in Cabal -------------------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: Cabal | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+---------------------------------- I get a segfault in the following program, compiled on OS X with the development version of GHC (last commit 50e4d40f88c3eee41384efacfd83f73305e2210d), run with the command `./Setup configure`. A `.cabal` file is not needed to produce the error. {{{ -- ghc --make Setup.hs import Distribution.Simple main = defaultMainWithHooks simpleUserHooks }}} I discovered the problem when installing `llvm-general-pure`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 20:56:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 20:56:05 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.fee64594f0b43bf9e1ef8715136f291e@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): Hi Did with the git HLearn folder: cabal sandbox init cabal install --only-dependencies took 2 hours to install and loaded the code within ghci and got the same error message ?? any ideas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 22:16:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 22:16:20 -0000 Subject: [GHC] #8729: Compile crashed with panic! (the 'impossible' happened) Message-ID: <047.c9be187a29c23ba9903679e11543dcb7@haskell.org> #8729: Compile crashed with panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: zabirauf | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.4.1 Keywords: panic! impossible | Operating System: Linux compiler crash | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following code results in a compiler crash with error ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): nameModule show{tv a9N} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The code can be found at [http://pastie.org/8692515] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 2 23:29:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Feb 2014 23:29:27 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.8599f49ebeeb46c3bded55d52efdbcb3@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): does the code work when you compile it? (ie have a main = foo in the module and build it with ghc). There are certain problems with ghci (though i have no idea how it could be tripping them.) @teuffy, could you share {{ghc --info}} and {{cabal --version}} with us please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 00:26:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 00:26:30 -0000 Subject: [GHC] #8729: Compile crashed with panic! (the 'impossible' happened) In-Reply-To: <047.c9be187a29c23ba9903679e11543dcb7@haskell.org> References: <047.c9be187a29c23ba9903679e11543dcb7@haskell.org> Message-ID: <062.585e5136183e0a5f31c31db0546dcd67@haskell.org> #8729: Compile crashed with panic! (the 'impossible' happened) ---------------------------------------+----------------------------------- Reporter: zabirauf | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by hvr): * status: new => closed * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 7.6.1 * keywords: panic! impossible compiler crash => * resolution: => fixed Old description: > The following code results in a compiler crash with error > ghc: panic! (the 'impossible' happened) > (GHC version 7.4.1 for x86_64-unknown-linux): > nameModule show{tv a9N} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > The code can be found at [http://pastie.org/8692515] New description: The following code results in a compiler crash with error {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): nameModule show{tv a9N} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code can be found at [http://pastie.org/8692515] -- Comment: Thanks for the report, however this has been fixed in GHC 7.6.1 already, which gives the following compile error: {{{ t8729.hs:1:65: Illegal deriving item `show' In the data declaration for `LinkedList' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 02:26:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 02:26:02 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.c4b50399118893a32b573342659c7e70@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): Replying to [comment:5 carter]: > does the code work when you compile it? (ie have a main = foo in the module and build it with ghc). There are certain problems with ghci (though i have no idea how it could be tripping them.) > > @teuffy, could you share {{ghc --info}} and {{cabal --version}} with us please? The code works when compiled the output -> Categorical {pdfmap = fromList [(Red,9.0),(Green,4.0),(Blue,3.0),(White,1.0)]} cabal --version cabal-install version 1.18.0.2 using version 1.18.1 of the Cabal library ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory- overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 02:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 02:32:21 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.09c8bcaa3001a154d9a68728e52908e8@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): @carter I don't know if it has an impact on ghci but on this machine I installed the haskell-framework with apt-get install (ubuntu precise) + cabal install cabal-install -> ghc 7.4 and cabal 1.18 but for HLearn ghc 7.6 is needed so I did the following sudo apt-get --purge remove ghc sudo apt-get --purge remove cabal-install sudo apt-add-repository ppa:typeful/ghc-7.6.3 sudo apt-add-repository ppa:typeful/cabal-install sudo apt-get update sudo apt-get install ghc cabal-install -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 04:35:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 04:35:41 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.4e6fcde01945197d89ea0143d76aa9b7@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): @teuffy, if you could get a minimal test case that doesn't pull in all of hlearns deps, that be great HOWEVER I suspect that you're tripping on one of the known issues that resolved with GHC 7.8 (and HEAD) for GHCI. Also, did you file bug reports with mike before escalating to trac? if you can get ghc 7.8 rc installed, and test your example code in ghci there, that would help narrow things down eg {{{ sudo add-apt-repository -y ppa:hvr/ghc sudo apt-get update sudo apt-get install cabal-install-1.18 ghc-7.8.1 }}} then massage the libs to work on 7.8 and test there, that would help. ALTERNATIVELY: how much space is on the vm? does it have swap space? it could be that the vm ran of memory/swap during linking in a weird way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 04:46:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 04:46:36 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.c9319b9658fc8c826d3a4516fd494d4e@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): a - minimal test ?? what should I do exactly as "doesn't pull in all of hlearns deps" is not clear for me. I am a newbie ... c - memory ram 2048 MB . I haven't set the swap space (vagranfile set to 2048MB) b - I will try to install 7.8 and keep you posted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 05:10:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 05:10:41 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.381fedbca496866806a7b89cb72a7aca@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): @carter "then massage the libs to work on 7.8 and test there, that would help." What should I do exactly here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 05:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 05:27:36 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.f15ef4fa5c1c282362f3cc2f24b497f4@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): hrm? not sure i understand what you're asking. (and i'm sorry if i'm causing any confusion) Also, have you given mike izbiki a bug report (the HLearn)? It may be a known issue he's worked around (if so, please share with us too) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 05:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 05:37:24 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.da4ec1771d3112c5ddeb9ac0641ae2b5@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): I installed ghc-7.8.1 and ghc --version still showing 7.6.3. What should I do to test my code under ghc 7.8.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 05:45:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 05:45:21 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.bb43ffcf19f376b0c86ad2b4f9128d86@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): @carter Bug is gone within ghci after the installation of ghc 7.8.1. Many thanks for your help and support -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 05:51:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 05:51:52 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.72f1a8dd5a97aea3e604cf41061d59cb@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by teuffy): Well .... sorry about my previous statement but not really gone as "loadArchive "/home/vagrant/.cabal/lib/x86_64-linux- ghc-7.6.3/HLearn-2.0.0.0/libHSHLearn-2.0.0.0.a": failed" still showing 7.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 06:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 06:30:58 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.a168efabccfa1b3666c15083334d67be@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): make sure the only ghc setup is 7.8, cabal install the hlearn deps (which may require some patches), and run the example? but first take a break and file a bug report with the hlearn author too I think -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 07:23:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 07:23:23 -0000 Subject: [GHC] #8730: Invalid Unicode Codepoints in Char Message-ID: <047.d29dc672b6ffe33afb3c95f4df30833b@haskell.org> #8730: Invalid Unicode Codepoints in Char ------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: unicode | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 14:24:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 14:24:06 -0000 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@haskell.org> Message-ID: <061.7c10a3e7029d5305e7eb2ebfe06eaaa7@haskell.org> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: Unknown/Multiple | allocation Type of failure: Incorrect result | Architecture: Unknown/Multiple at runtime | Difficulty: Unknown Test Case: | Blocked By: concurrent/should_run/T367, | Related Tickets: concurrent/should_run/T367_letnoescape| Blocking: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => concurrent/should_run/T367, concurrent/should_run/T367_letnoescape -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 17:48:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 17:48:43 -0000 Subject: [GHC] #8727: HLearn test on ubuntu Precise x64 within vagrant Box In-Reply-To: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> References: <045.d4c9fc1f73311b6c71d797d34da7ccec@haskell.org> Message-ID: <060.c7ddfc7e95e3a2738f185ffe673c490c@haskell.org> #8727: HLearn test on ubuntu Precise x64 within vagrant Box -----------------------------+---------------------------------- Reporter: teuffy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by hvr): Replying to [comment:12 teuffy]: > I installed ghc-7.8.1 and ghc --version still showing 7.6.3. What should I do to test my code under ghc 7.8.1? Fyi, when using the `ppa:hvr/ghc` PPAs you need to put e.g. `/opt/ghc/7.8.1/bin` early enough in your PATH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 17:58:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 17:58:22 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.e6144f7f82129ea0fbc4e4ce8a170c99@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by lnandor): I have tried to fix the bug by replacing select with pselect to ignore the SIGVTALRM signal sent by the runtime, but to properly terminate when SIGPIPE is received. [https://github.com/nandor/packages-base/compare/fix-8684?expand=1] {{{ diff --git a/GHC/IO/FD.hs b/GHC/IO/FD.hs index 2023526..0b0b1de 100644 --- a/GHC/IO/FD.hs +++ b/GHC/IO/FD.hs @@ -3,6 +3,7 @@ , NoImplicitPrelude , BangPatterns , DeriveDataTypeable + , InterruptibleFFI #-} {-# OPTIONS_GHC -fno-warn-identities #-} -- Whether there are identities depends on the platform @@ -395,7 +396,7 @@ setNonBlockingMode fd set = do ready :: FD -> Bool -> Int -> IO Bool ready fd write msecs = do - r <- throwErrnoIfMinus1Retry "GHC.IO.FD.ready" $ + r <- throwErrnoIfMinus1 "GHC.IO.FD.ready" $ fdReady (fdFD fd) (fromIntegral $ fromEnum $ write) (fromIntegral msecs) #if defined(mingw32_HOST_OS) @@ -405,7 +406,7 @@ ready fd write msecs = do #endif return (toEnum (fromIntegral r)) -foreign import ccall safe "fdReady" +foreign import ccall interruptible "fdReady" fdReady :: CInt -> CInt -> CInt -> CInt -> IO CInt -- --------------------------------------------------------------------------- @@ -502,7 +503,7 @@ indicates that there's no data, we call threadWaitRead. readRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO Int readRawBufferPtr loc !fd buf off len | isNonBlocking fd = unsafe_read -- unsafe is ok, it can't block - | otherwise = do r <- throwErrnoIfMinus1 loc + | otherwise = do r <- throwErrnoIfMinus1Retry loc (unsafe_fdReady (fdFD fd) 0 0 0) if r /= 0 then read diff --git a/GHC/IO/Handle/Text.hs b/GHC/IO/Handle/Text.hs index f182e7f..31f2cac 100644 --- a/GHC/IO/Handle/Text.hs +++ b/GHC/IO/Handle/Text.hs @@ -106,7 +106,6 @@ hWaitForInput h msecs = do writeIORef haCharBuffer cbuf' if not (isEmptyBuffer cbuf') then return True else do - r <- IODevice.ready haDevice False{-read-} msecs if r then do -- Call hLookAhead' to throw an EOF -- exception if appropriate diff --git a/cbits/inputReady.c b/cbits/inputReady.c index 51f278f..9d51750 100644 --- a/cbits/inputReady.c +++ b/cbits/inputReady.c @@ -22,9 +22,10 @@ fdReady(int fd, int write, int msecs, int isSock) #else ( 1 ) { #endif - int maxfd, ready; + int maxfd; fd_set rfd, wfd; - struct timeval tv; + struct timespec tv; + sigset_t set; FD_ZERO(&rfd); FD_ZERO(&wfd); @@ -39,16 +40,14 @@ fdReady(int fd, int write, int msecs, int isSock) */ maxfd = fd + 1; tv.tv_sec = msecs / 1000; - tv.tv_usec = (msecs % 1000) * 1000; + tv.tv_nsec = (msecs % 1000) * 1000000; - while ((ready = select(maxfd, &rfd, &wfd, NULL, &tv)) < 0 ) { - if (errno != EINTR ) { - return -1; - } - } + /* Block SIGVTALRM */ + sigprocmask(SIG_BLOCK, NULL, &set); + sigaddset(&set, SIGVTALRM); /* 1 => Input ready, 0 => not ready, -1 => error */ - return (ready); + return pselect(maxfd, &rfd, &wfd, NULL, &tv, &set); } #if defined(_MSC_VER) || defined(__MINGW32__) || defined(_WIN32) else { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 18:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 18:48:36 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.8d12fdaccc9332a1a02c2b206cf22714@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 18:57:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 18:57:19 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.c4c37fae6864c415336354fda3e9f6af@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): Is this bug possibly the culprit behind https://github.com/bscarlet/llvm- general/issues/84#issuecomment-33917697 ? namely ``lookupSymbol failed in relocateSection (RELOC_GOT) /usr/local/Cellar/llvm33/3.3/lib/llvm-3.3/lib/libLLVMSupport.a: unknown symbol `___dso_handle' ghc: unable to load package `llvm-general-3.3.8.2' `` this happens in the context of trying to build llvm-general with haskell shared libs while liking to the static lib version of llvm's libs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 19:02:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 19:02:02 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.e502a56a82516f30b7b2096b5800c65b@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): or more likely https://github.com/bscarlet/llvm- general/issues/84#issuecomment-33923968 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 3 23:44:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Feb 2014 23:44:34 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors Message-ID: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc1 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times. This seems to related to how GHC handles a many constructor data type with overlapping field names. the time is nearly the same for building a static module with O1 and O2 {{{ carter repoScratcher/bad-ast ? time ghc Constant.hs -O2 1 ? [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total }}} {{{ carter repoScratcher/bad-ast ? time ghc Constant.hs -O1 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total }}} heck even with -O0 its slow (though not terrible) {{{ carter repoScratcher/bad-ast ? time ghc Constant.hs -O0 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total }}} Seems like there might something wrong in how we handle data types like this, the complexity need not -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 00:10:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 00:10:55 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.b9049aa50804d2e5b1af873408ae6ff6@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by nomeata): After being told that others have not problem with `DESTDIR`, I narrowed it down a bit. I believe that `DESTDIR` can only work if `$ghclibexecdir` = `$ghclibdir`. Then, executing `$ghclibexecdir/bin/ghc` works because of the rpath of the binaries: {{{ 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../terminfo-0.4.0.0:$ORIGIN/../bin-package- db-0.0.0.0:$ORIGIN/../binary-0.7.1.0:$ORIGIN/../Cabal-1.18.1.3:$ORIGIN/../process-1.2.0.0:$ORIGIN/../pretty-1.1.1.1:$ORIGIN/../directory-1.2.0.2:$ORIGIN/../unix-2.7.0.0:$ORIGIN/../time-1.4.1:$ORIGIN /../old- locale-1.0.0.6:$ORIGIN/../filepath-1.3.0.2:$ORIGIN/../containers-0.5.4.0:$ORIGIN/../bytestring-0.10.4.0:$ORIGIN/../deepseq-1.3.0.2:$ORIGIN/../array-0.5.0.0:$ORIGIN/../base-4.7.0.0:$ORIGIN /../integer-gmp-0.5.1.0:$ORIGIN/../ghc-prim-0.3.1.0:$ORIGIN/../rts-1.0] }}} Debian has `$ghclibexecdir = $ghclibdir/lib`, so this breaks. The relative path here (`$ORIGIN/../$d`) is hard-coded in source:rules /build-package-way.mk and this issue was last addressed by [7dd7008f], in response to #3072. To fix this properly, instead of `..` one would have to calculate the relative path from `$ghclibexecdir/bin` to `$ghclibdir`. Or simply, and officially stop supporting such directory layouts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 01:40:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 01:40:10 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.740d92e5cc378bce9f3b347bfb6a30b0@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Comment (by rleslie): May I ask what the next steps for this are? Is the patch likely to be merged into the 7.8 branch? Or does it still warrant further contemplation and discussion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:17:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:17:38 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention Message-ID: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> #8732: Global big object heap allocator lock causes contention ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The lock allocate() takes when allocating big objects hurts scalability of I/O bound application. Network.Socket.ByteString.recv is typically called with a buffer size of 4096, which causes a ByteString of that size to be allocate. The size of this ByteString causes it to be allocated from the big object space, which causes contention of the global lock that guards that space. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:21:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:21:19 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops Message-ID: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:42:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:42:36 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.f491e06f987ac9e84b5ebfe57eaee11b@haskell.org> #8732: Global big object heap allocator lock causes contention -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > The lock allocate() takes when allocating big objects hurts scalability > of I/O bound application. Network.Socket.ByteString.recv is typically > called with a buffer size of 4096, which causes a ByteString of that size > to be allocate. The size of this ByteString causes it to be allocated > from the big object space, which causes contention of the global lock > that guards that space. > > See http://www.yesodweb.com/blog/2014/02/new-warp for a real world > example. New description: The lock `allocate` takes when allocating big objects hurts scalability of I/O bound application. `Network.Socket.ByteString.recv` is typically called with a buffer size of 4096, which causes a `ByteString` of that size to be allocated. The size of this `ByteString` causes it to be allocated from the big object space, which causes contention of the global lock that guards that space. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:43:20 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.cbff44a7b3d83cf8969cb871d1dd48fb@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by tibbe: Old description: > Network applications often call send followed by recv, to send a message > and then read an answer. This causes syscall traces like this one: > > {{{ > recvfrom(13, ) -- Haskell thread A > sendto(13, ) -- Haskell thread A > recvfrom(13, ) = -1 EAGAIN -- Haskell thread A > epoll_ctl(3, ) -- Haskell thread A (a job for the IO > manager) > recvfrom(14, ) -- Haskell thread B > sendto(14, ) -- Haskell thread B > recvfrom(14, ) = -1 EAGAIN -- Haskell thread B > epoll_ctl(3, ) -- Haskell thread B (a job for the IO > manager) > }}} > > The recvfrom call always fails, as the response from the partner we're > communicating with won't be available right after we send the request. > > We ought to consider descheduling the thread as soon as sending is > "done". The hard part is to figure out when that is. > > See http://www.yesodweb.com/blog/2014/02/new-warp for a real world > example. New description: Network applications often call `send` followed by `recv`, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The `recvfrom` call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:48:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:48:29 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.e9b50f7249bee48eaa2352766652e19d@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): could it be done by having the end of the send call always yield? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 05:51:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 05:51:25 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.263b81c8c9850ce0f0ee9c2967e71d3a@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): @carter it could, but then we might end up yielding before all the content has been sent (in case it's spread over several `send`s). We could think about having something similar to `TCP_CORK` to have the client communicate when it's ready to yield. On the other hand, if the client has to deal with this issue she might as well yield manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 06:09:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 06:09:39 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.fd9ba40171d1d35b6d68338766ab1b4b@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): yeah, you're right. In which case, might it make sense to have clear breadcrumbs for this technique in network or the like? eg (a strawman mind you) {{{ withYield :: IO a-> IO () withYield m = do m ; yield }}} this is probably the most wrong way possible, but I don't mean it as a serious suggestion. Merely that making yield more visible in the api surface might be a "social" approach to mitigate things. Eg, its always safe to add yields to code, but as you say, its not a good idea to just sprinkle it around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 06:26:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 06:26:59 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.224ecf60ec2bc60811f3c475cedbb5a3@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by etrepum): Is the IO manager the right layer to be approaching this from? Not all protocols are going to be strictly request/response with no pipelining or multiplexing like vanilla HTTP is. Why not implement this at a higher level in a library that encapsulates these best practices for various sorts of protocols? A good start may be to add this to the Performance Resource: http://www.haskell.org/haskellwiki/Performance (which looks old but that's what came up when I searched). Erlang publishes an Efficiency Guide that is nice (but doesn't cover any networking topics) http://erlang.org/doc/efficiency_guide/users_guide.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 06:31:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 06:31:36 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.7579fa39d48372844718759d1f8c5c1b@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): yeah, that might be a good approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 06:35:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 06:35:01 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.dbe5cfdad83e46270cf8e766fdc1e980@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) ------------------------------------------------+-------------------------- Reporter: rleslie | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: libraries/haskell2010 | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #1042 ------------------------------------------------+-------------------------- Changes (by carter): * type: bug => feature request * milestone: 7.8.1 => 7.10.1 Comment: @rleslie, I spoke with a few ghc devs. We definitely want to improve this. 1) this won't happen for 7.8. For several main reasons a) 7.8 is already in RC. So 7.8.1 is only going to get bug fixes relative to the current Release Candidate b) its actually a pretty reasonable default currently, because as rwbarton argues, theres no "unique" solution concept. c) it should really only be done as part of a whole sale cleanup of how ghc handles ints and friends internally. Basically, this ticket is a great motivating example for cleaning up the numbers situation in ghc. And Fixing this up a bit more systematically is definitely something thats can make it into 7.10 (time / resources permitting of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 07:08:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 07:08:13 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.dba4ba6df45bb04108b3bb4c7c6b0551@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 07:47:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 07:47:43 -0000 Subject: [GHC] #8690: Failed to compile Win32 libraries using 64 bit GHC. In-Reply-To: <055.b6678f8a776bfc0e56a242b0c9070f8a@haskell.org> References: <055.b6678f8a776bfc0e56a242b0c9070f8a@haskell.org> Message-ID: <070.2b6aa1f90dc22916d15f007400f470f2@haskell.org> #8690: Failed to compile Win32 libraries using 64 bit GHC. ---------------------------------------+---------------------------------- Reporter: andrewrademacher | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by hvr): * status: new => closed * resolution: => duplicate Comment: duplicate of #7134 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 07:52:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 07:52:10 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.45e3fa6093f2550d97d6e8607d097787@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * cc: hvr (added) * failure: None/Unknown => Runtime performance bug * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 07:53:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 07:53:43 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.a29f5e0e865086ded3c51cb1e644a631@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * cc: hvr (added) * failure: None/Unknown => Runtime performance bug * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:40:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:40:42 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.9c0850806c0032493f6349f629e3f473@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. We'll need to update Cabal submodule in HEAD and 7.8 when we do the actual release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:43:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:43:42 -0000 Subject: [GHC] #7646: resource busy (file is locked) with multi-threaded file ops In-Reply-To: <049.fa814dd056739342ea7462a912429904@haskell.org> References: <049.fa814dd056739342ea7462a912429904@haskell.org> Message-ID: <064.0e96fc72861bd13e11f03365ff36433c@haskell.org> #7646: resource busy (file is locked) with multi-threaded file ops ------------------------------------------------+-------------------------- Reporter: StefanWehr | Owner: Type: bug | simonmar Priority: high | Status: closed Component: libraries/base | Milestone: 7.6.3 Resolution: fixed | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Fixed in 7.8/HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:43:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:43:51 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.4ea57f6c30793f677686a71493fd71f3@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by schyler): If I understand correctly, this can be implemented as a state machine. Each thread can have a "last IO action" state which gets reset when it yields and set to some constant on send/recv. Then, if you call recv and it's still in send mode, yield automatically (and yield would set it back to NULL). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:44:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:44:36 -0000 Subject: [GHC] #7636: threadStackUnderflow: not enough space for return values In-Reply-To: <047.c5f9bd016324deecee963e4ed9ffea48@haskell.org> References: <047.c5f9bd016324deecee963e4ed9ffea48@haskell.org> Message-ID: <062.d470b2822e2580a47eb42870e66e7af7@haskell.org> #7636: threadStackUnderflow: not enough space for return values ---------------------------------+---------------------------------- Reporter: mojojojo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Closing. There won't be a 7.6.4 as we're doing 7.8 right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:45:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:45:28 -0000 Subject: [GHC] #5909: Segfault with multi-threaded retainer profiling In-Reply-To: <043.7f37e849253cfc8e4ab305c3508215b9@haskell.org> References: <043.7f37e849253cfc8e4ab305c3508215b9@haskell.org> Message-ID: <058.03b8b6f36ae108f2e6bfd288671336d7@haskell.org> #5909: Segfault with multi-threaded retainer profiling -----------------------------------+---------------------------------- Reporter: akio | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * cc: simonmar (added) * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:46:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:46:05 -0000 Subject: [GHC] #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc In-Reply-To: <047.20d3f3801a1860868ddc1579dc689295@haskell.org> References: <047.20d3f3801a1860868ddc1579dc689295@haskell.org> Message-ID: <062.45866eefc72c5b855e407ab781aeb366@haskell.org> #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc ---------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8282 ---------------------------------+---------------------------------- Changes (by thoughtpolice): * cc: hvr (added) * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:47:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:47:08 -0000 Subject: [GHC] #7850: Strangely high memory usage on optimized Ackermann function In-Reply-To: <044.5932b18181fc435c678016ce509ebe78@haskell.org> References: <044.5932b18181fc435c678016ce509ebe78@haskell.org> Message-ID: <059.8f678d2c7459be5fcabd34c9aa101f84@haskell.org> #7850: Strangely high memory usage on optimized Ackermann function --------------------------------------------+------------------------------ Reporter: dolio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T7850 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:47:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:47:31 -0000 Subject: [GHC] #7850: Strangely high memory usage on optimized Ackermann function In-Reply-To: <044.5932b18181fc435c678016ce509ebe78@haskell.org> References: <044.5932b18181fc435c678016ce509ebe78@haskell.org> Message-ID: <059.070fa705b08d347fb152449b1503702f@haskell.org> #7850: Strangely high memory usage on optimized Ackermann function --------------------------------------------+------------------------------ Reporter: dolio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T7850 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): Fixed and merged in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:47:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:47:45 -0000 Subject: [GHC] #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc In-Reply-To: <047.20d3f3801a1860868ddc1579dc689295@haskell.org> References: <047.20d3f3801a1860868ddc1579dc689295@haskell.org> Message-ID: <062.b8a3b8621eb6e42d6fa8d7cd3b692e42@haskell.org> #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc ---------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8282 ---------------------------------+---------------------------------- Comment (by thoughtpolice): Fixed and merged in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:48:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:48:50 -0000 Subject: [GHC] #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid In-Reply-To: <052.b94d1bfd5485a4500b45d5e84e1e73bd@haskell.org> References: <052.b94d1bfd5485a4500b45d5e84e1e73bd@haskell.org> Message-ID: <067.a260da269a6264dddb3b6669efd07050@haskell.org> #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:48:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:48:58 -0000 Subject: [GHC] #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid In-Reply-To: <052.b94d1bfd5485a4500b45d5e84e1e73bd@haskell.org> References: <052.b94d1bfd5485a4500b45d5e84e1e73bd@haskell.org> Message-ID: <067.82e5a7cc8a158f857abd6ad45a85f0fb@haskell.org> #7714: The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid -------------------------------------+------------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): In HEAD and 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:50:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:50:14 -0000 Subject: [GHC] #7919: Heap corruption (segfault) from large 'let' expression In-Reply-To: <045.3707d678a38441ef54b667e63e238d84@haskell.org> References: <045.3707d678a38441ef54b667e63e238d84@haskell.org> Message-ID: <060.074c96f2896b4deb2650fd257dd01e05@haskell.org> #7919: Heap corruption (segfault) from large 'let' expression -----------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: simonmar => * status: merge => new Comment: If this is still crashing, then we need more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:50:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:50:23 -0000 Subject: [GHC] #7919: Heap corruption (segfault) from large 'let' expression In-Reply-To: <045.3707d678a38441ef54b667e63e238d84@haskell.org> References: <045.3707d678a38441ef54b667e63e238d84@haskell.org> Message-ID: <060.095d80ac874d640d917a332b26ee0e3e@haskell.org> #7919: Heap corruption (segfault) from large 'let' expression -----------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:54:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:54:38 -0000 Subject: [GHC] #7773: Waiting on non-kqueue supported files on OS X In-Reply-To: <053.4facf266f2cb122f83378cb6290eca2e@haskell.org> References: <053.4facf266f2cb122f83378cb6290eca2e@haskell.org> Message-ID: <068.ce3181c8c7910fa51001ec79582dc19a@haskell.org> #7773: Waiting on non-kqueue supported files on OS X ------------------------------------------------+-------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | AndreasVoellmy Priority: normal | Status: closed Component: libraries/base | Milestone: 7.8.1 Resolution: fixed | Version: 7.7 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: HEAD has undergone some refactoring, but it looks like this is merged: https://ghc.haskell.org/trac/ghc/browser/base/GHC/Event/Manager.hs?rev=ff8200afda9b7ada28e1199a109b6b5acf8c30d6#L321 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:56:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:56:03 -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.4322f741ce4abdd72ecc242e91b51a9d@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * owner: ezyang => * status: merge => new Comment: This shouldn't be 'merge' - we'll need more info it looks like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:56:27 -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.9a644a1f93e69b9d11d14dbce9c1d869@haskell.org> #703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 10:56:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 10:56:50 -0000 Subject: [GHC] #7693: Flush .hp file at the end of each sample In-Reply-To: <043.56d888a45670c39a2d888873fc1a2c95@haskell.org> References: <043.56d888a45670c39a2d888873fc1a2c95@haskell.org> Message-ID: <058.1031236e9aab2b9ad19eeb957ea2e6a3@haskell.org> #7693: Flush .hp file at the end of each sample -------------------------------------+------------------------------------ Reporter: akio | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.6.3 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: simonmar (added) * status: merge => closed * resolution: => fixed Comment: Merged in HEAD/7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:00:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:00:57 -0000 Subject: [GHC] #8717: Segfault in 64-bit Windows GHCi In-Reply-To: <044.52006547921df8c64442c64892015775@haskell.org> References: <044.52006547921df8c64442c64892015775@haskell.org> Message-ID: <059.57325db125f656dbf3165ee62199756c@haskell.org> #8717: Segfault in 64-bit Windows GHCi -------------------------------+---------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Difficult (2-5 days) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------------- Comment (by Austin Seipp ): In [changeset:"2b33f6e8045fcd00f19883bb5e8895cbaf1bf81e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2b33f6e8045fcd00f19883bb5e8895cbaf1bf81e" Final fix to #7134 (and #8717 as well.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:00:58 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.1f967620b7eedd2cec6247ee064af11d@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"2b33f6e8045fcd00f19883bb5e8895cbaf1bf81e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2b33f6e8045fcd00f19883bb5e8895cbaf1bf81e" Final fix to #7134 (and #8717 as well.) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:02:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:02:03 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.e09f0a07852c54495d2d1e64f6c0a217@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:04:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:04:20 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.644d7fe4bcf51110da9b2cc266ba46a2@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Integer-gmp Test Case: | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Merged to HEAD/7.8 by Herbert. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:05:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:05:28 -0000 Subject: [GHC] #8115: GHC 64-bit Windows build failures with LLVM In-Reply-To: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> References: <046.85b4ba291c9a7177535aee44db08c94a@haskell.org> Message-ID: <061.26be26d388cf456d78dac9cd1ae7a989@haskell.org> #8115: GHC 64-bit Windows build failures with LLVM ---------------------------------+------------------------------------ Reporter: schyler | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by schyler): * priority: high => highest Comment: Fail to compile at all is probably just as important as some of the linker errors which have Highest priority. Maybe it's OK if I promote this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:09:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:09:55 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal In-Reply-To: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> References: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> Message-ID: <062.096139a9054d3b0b3908857d069d581e@haskell.org> #8728: Segmentation fault in Cabal --------------------------------------+----------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Cabal Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+----------------------------- Comment (by thoughtpolice): Can you provide the exact steps you did? Also, can you try the RC1 binaries? And what platform are you on, OS version, etc etc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 11:15:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 11:15:24 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.c757da8a8e80e0b6856ad16eb7bd7d06@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.7 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 17:11:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 17:11:36 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.89e4ae09eb3f2d15e5b22729ad2ea881@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:5 etrepum]: > Is the IO manager the right layer to be approaching this from? Not all protocols are going to be strictly request/response with no pipelining or multiplexing like vanilla HTTP is. > > Why not implement this at a higher level in a library that encapsulates these best practices for various sorts of protocols? Good question. I considered this before filing the bug. One argument for why this should work without user interaction, in addition to the standard "it's nice if it just works" argument, is that if we didn't use the I/O manager but instead normal blocking syscalls, we'd end up with better behavior in this case. > A good start may be to add this to the Performance Resource: http://www.haskell.org/haskellwiki/Performance (which looks old but that's what came up when I searched). Erlang publishes an Efficiency Guide that is nice (but doesn't cover any networking topics) http://erlang.org/doc/efficiency_guide/users_guide.html I'm planning to add a note to the network package's docs when I find the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 17:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 17:41:15 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal In-Reply-To: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> References: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> Message-ID: <062.b87a35ce5331e2499e5c922a6f0d29d9@haskell.org> #8728: Segmentation fault in Cabal --------------------------------------+----------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Cabal Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+----------------------------- Comment (by heatsink): I am using Mac OS 10.6.8. I can not find an RC1 binary for this OS. There are binaries for Mac OS 10.7 and 10.9. The problem appeared when I updated a preexisting repository to get the fix for #8180. Here are the steps as I remember them. I ran `./sync-all pull --rebase; make clean; configure --prefix=$HOME/env/ghc; make; make install`. GHC 7.4.1 and Haskell platform 2012.2.0.0 were used to bootstrap. I ran into the bug after installing some packages, but the bug seems to depend only on the libraries included with GHC. The bug is produced by adding the install path to `PATH`, writing the program to `Setup.hs`, compiling it with `ghc --make`, and running `./Setup configure`. My local changes to the RTS were `#ifdef`'d out during the test. I haven't tested a pristine copy of the sources. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 18:28:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 18:28:32 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.fc6dfc54a728c22404d78e82f75d6344@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Thanks. It is merged in HEAD but still not in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 18:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 18:47:41 -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.1796826e141080551eba9d1d579f534a@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: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 18:56:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 18:56:36 -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.1bb1bad4df5bf48b317c250c2d0eb3e8@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: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by carter): rwbarton (on irc) noted this single module also has a nearly 1mb object file! Also apparently most of the code generated / time might be related to the Read and Show instances. (i've not check the latter myself, but sounds plausible) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 20:01:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 20:01:59 -0000 Subject: [GHC] #2401: aborting an STM transaction should throw an exception In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@haskell.org> References: <043.102536ca2a3e567cb6677ad0a9004c1b@haskell.org> Message-ID: <058.5b60ae9c6eb2ce686967d49dc992d689@haskell.org> #2401: aborting an STM transaction should throw an exception ------------------------------------------------+-------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rleslie): * cc: rob@?, simonmar (added) Comment: As someone who has recently been bitten by this while trying to implement a pure interface to an external library via FFI, I would like to express my enthusiasm for its resolution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 21:07:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 21:07:42 -0000 Subject: [GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion In-Reply-To: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> References: <043.229b17c6b043d171889e26950a7c81e6@haskell.org> Message-ID: <058.8c948c99115e151b6f72052aedcce444@haskell.org> #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion -------------------------------------+------------------------------------ Reporter: ion1 | Owner: rrnewton Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: fusion Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4218 -------------------------------------+------------------------------------ Changes (by rrnewton): * owner: => rrnewton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 21:25:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 21:25:18 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.2bcff276d2b9eddd9e7588076b1149b8@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by George): * cc: hvr (added) Comment: same results in 7.8 RC1 on Mac OS 10.9.1 as my results above -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 21:31:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 21:31:15 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.906e4bfa92bd57a1ed8a370e1ece1c3f@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by George): * version: 7.6.2 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 21:37:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 21:37:25 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.c5982502ed949668cb78ae1b2048155b@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by carter): GHCI in my 7.8 RC build has no errors with either example. (ie I get a very very large number printed out) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 21:41:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 21:41:23 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.437dbe6fef35e7076d2e9059062f478b@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by carter): my ghc build is a bindist here https://github.com/cartazio/ghc/releases/tag/carters-build-7.8-preRC1 from commit 12853f4dd3950b7bf9241f7394cc2f40d0b90c9a it may be related to that. heres my settings file {{{ carter ~ ? ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","gcc-4.8") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc-3.4") ,("LLVM opt command","/usr/local/bin/opt-3.4") ,("Project version","7.8.20140130") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.20140130") ,("Global Package DB","/usr/local/lib/ghc-7.8.20140130/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:00:56 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files Message-ID: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files --------------------------+------------------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result at runtime Unknown/Multiple | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:03:22 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.54e9dbd596a92fb3f9bb79c3dbbeed0e@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: Resolution: | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by George): Following is script showing that 7.8.1-rc1 ghci won't load compiled files on Mac {{{ /usr/local/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... bash-3.2$ /usr/local/bin/ghci GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> but it did load .o files on 7.6.3: /usr/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... bash-3.2$ /usr/bin/ghci GHCi, version 7.6.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> :load Bug Ok, modules loaded: Main. Prelude Main> :show modules Main ( Bug.hs, Bug.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:12:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:12:55 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac Message-ID: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> #8735: hpc doesn't work on Mac ------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:14:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:14:46 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.4b39c90661260d5d9eecfe9c76acc8f2@haskell.org> #8735: hpc doesn't work on Mac ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by George): {{{ hpc doesn't work: hpc --version dyld: Library not loaded: @rpath/libHShpc-0.6.0.1-ghc7.8.20140130.dylib Referenced from: /usr/local/bin/hpc Reason: image not found Trace/BPT trap: 5 }}} this results in error popups when doing cabal install e.g. cabal install vector but this doesn't seem to affect the install -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:17:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:17:49 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.de87c17652585ba6834c36c3cc2f7f34@haskell.org> #8735: hpc doesn't work on Mac ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by carter): george, whats your ghc --info say? mine has {{{ ? ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","gcc-4.8") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc-3.4") ,("LLVM opt command","/usr/local/bin/opt-3.4") ,("Project version","7.8.20140130") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.20140130") ,("Global Package DB","/usr/local/lib/ghc-7.8.20140130/package.conf.d") ] }}} (i'm using my own RC build rather than Austin's) could you paste your "ghc --info" please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:19:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:19:23 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.5e9ad489144e06c55a21f0f6bc36c776@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: Resolution: | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by hvr): ...that's actually by design, as 7.8.1 switched to using the system linker in combination with DSOs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:22:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:22:55 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.0aa6dd7c4636ad3cfa5a93f49a13345a@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by ezyang): NB: #7134 has since been merged, so that patch needs tob e taken out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:44:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:44:38 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.94bf1e966e2ea912b062e5f7a2e639b0@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by rwbarton): George, thanks for following up on this. Could you attach a crash report for the bus error like the one Doug310 posted above? (or Austin, if you can reproduce this also?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:46:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:46:39 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.fd2e883019443116d5e983d6f70eaf5a@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Doug310): Thanks for attempting to address this. It's nice to see some traction after a year. :) It would be great if the 64-bit GHC/GHCi would become as stable as the 32-bit on Mac OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:47:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:47:33 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.8ee26c42d3cf858c27e459fe35bc9961@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by Doug310): Also note that I just tried various random large numbers after I first noticed the problem. It crashed on some, but not all, which made the underlying reason for the issue mystifying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:54:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:54:34 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.d3db9495c04569f324806643215729ab@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by hvr): btw, note that `(^)` for `Integer` is implemented via square-and-multiply, c.f. [http://hackage.haskell.org/package/base-4.6.0.1/docs/src/GHC- Real.html#%5E implementation in base]. So it might be interesting if one could find out which one of the several `Integer`-primop calls involved causes the actual fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 22:58:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 22:58:15 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.2ebf5de181613e2302853eb60b652738@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by ezyang): This patch seems to be enough to do that: {{{ diff --git a/rts/Linker.c b/rts/Linker.c index b9c8fd0..649df7f 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -211,9 +211,7 @@ static int ocAllocateSymbolExtras_ELF ( ObjectCode* oc ); static int ocVerifyImage_PEi386 ( ObjectCode* oc ); static int ocGetNames_PEi386 ( ObjectCode* oc ); static int ocResolve_PEi386 ( ObjectCode* oc ); -#if !defined(x86_64_HOST_ARCH) static int ocRunInit_PEi386 ( ObjectCode* oc ); -#endif static void *lookupSymbolInDLLs ( unsigned char *lbl ); static void zapTrailingAtSign ( unsigned char *sym ); static char *allocateImageAndTrampolines ( @@ -2875,10 +2873,8 @@ resolveObjs( void ) #if defined(OBJFORMAT_ELF) r = ocRunInit_ELF ( oc ); #elif defined(OBJFORMAT_PEi386) -#if !defined(x86_64_HOST_ARCH) /* It does not work on x86_64 yet. #8698. */ r = ocRunInit_PEi386 ( oc ); -#endif #elif defined(OBJFORMAT_MACHO) r = ocRunInit_MachO ( oc ); #else @@ -4415,7 +4411,6 @@ ocResolve_PEi386 ( ObjectCode* oc ) } /* It does not work on x86_64 yet. #8698. */ -#if !defined(x86_64_HOST_ARCH) static int ocRunInit_PEi386 ( ObjectCode *oc ) { @@ -4458,7 +4453,6 @@ ocRunInit_PEi386 ( ObjectCode *oc ) freeProgEnvv(envc, envv); return 1; } -#endif #endif /* defined(OBJFORMAT_PEi386) */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 23:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 23:07:14 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately Message-ID: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that GHCi generally defaults to dynamic linking, it handles dynamic object files. But it doesn't implicitly handle the `-dynamic-too` case appropriately: {{{ $ cat Test.hs main = return () $ ./inplace/bin/ghc-stage2 -dynamic Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> ^D $ ./inplace/bin/ghc-stage2 -dynamic-too Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} Also: {{{ $ ./inplace/bin/ghc-stage2 --interactive Test.dyn_o GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Warning: ignoring unrecognised input `Test.dyn_o' Prelude> }}} but it does handle the `.o` case. This should all be fixed and merged to 7.8 since it'll likely be very annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 23:07:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 23:07:36 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.d8c117c3b26f3535202af540dd2967b9@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => invalid Comment: Herbert is correct. This is by design - GHCi now loads dynamic object files, not static object files. But GHC itself still defaults to dynamic linking. However, there is still a bug here: GHCi doesn't handle `.dyn_o` correctly. I've filed #8736 for that. Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 23:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 23:10:05 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.82d18bd03c5d165961b1c4177322f2e7@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: trommler => thoughtpolice * milestone: => 7.8.1 Comment: Good catch, total failure on my part. I'll fix and merge to 7.8 as I now have a fancy new PPC64 machine to test with! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 4 23:30:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Feb 2014 23:30:43 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.aa0c77b16961d561eda285a566039df5@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+---------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by ezyang): I've identified the bug: our section name comparison function only handles short names, but the relocation here is a long name. Cooking up a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 00:13:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 00:13:57 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.881e0ff953ae41694f0c76e1af5b5bfa@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Changes (by ezyang): * difficulty: Unknown => Easy (less than 1 hour) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 00:30:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 00:30:24 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.dbf64d87383a0bbc3a93c7d5d864b8c1@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): It is a good thing that these blocks are considered big blocks, since we don't really want to be copying the buffers around. So one thought might be to make the large block list in generation-0 per-thread, and perform allocations from a thread-local block list. But you have to be careful: objects that are larger than a block need contiguous blocks, so unless you are only going to enable this for large objects that still fit in a single block, you'll have to maintain multiple lists with the sizes you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 00:38:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 00:38:06 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.d17521fb83748be37976e7335949e8b3@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): > But you have to be careful: objects that are larger than a block need contiguous blocks, so unless you are only going to enable this for large objects that still fit in a single block, you'll have to maintain multiple lists with the sizes you want. I think malloc already does that, so we could copy whatever they do perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 01:22:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 01:22:59 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.f83d99a94f878d47cfe24d02dfd268a7@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Documentation | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by George): * component: GHCi => Documentation Comment: Then perhaps this is a doc bug? The GHC users guide. Ch.2, sec 3 on loading compiled code (../ghc-7.8.20140130/docs/users_guide/users_guide /ghci-compiled.html) has: "When loading up source modules with :load, GHCi normally looks for any corresponding compiled object files, and will use one in preference to interpreting the source if possible. Is there any design doc on the dynamic linking changes that you could point me to? Also some user documentation on how to use dyn_o files in conjunction with ghci? Thanks for everybody's quick response. I;m hoping there is some documentation that you can point me at to get up too speed. I've probably missed some obvious things. Thanks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 01:41:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 01:41:23 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.780b894382f6f815da1fb00b0f76998e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by George): output from ghc --info corresponding to crash report for bus error above {{{ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","@ArSupportsAtFile@") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.20140130") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.20140130") ,("Global Package DB","/usr/local/lib/ghc-7.8.20140130/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 01:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 01:48:25 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.2e72cf39de923abd6735c163ba7ce222@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Documentation | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by thoughtpolice): We highlighted it in the release notes ("As a result of this, GHCi (and Template Haskell) must now load dynamic object files...") but it perhaps warrants a bigger mention. I do think the part you quoted should be changed. The basic idea is pretty simple: GHC now just uses the system dynamic linker to load code. That's all. So it needs dynamically linked object files. GHC normally compiles statically, though (and there are advantages to this.) So now you need to compile "statically and dynamically at the same time." I'll revise this in the user manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 01:54:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 01:54:12 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.7dc334b380c9faa47c08bb1630498901@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by carter): hrm `` ("ar supports at file","@ArSupportsAtFile@")`` could that be problematic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 02:33:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 02:33:24 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.dc5e0ee058cd4fa75f864ad39471bc59@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): It's pretty standard, yes (we implement for handling the global block pool), but it does mean all of that code would have to be made thread- local. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 02:54:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 02:54:49 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.c6c5e28e02d6489bb88af2ad28301a3e@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:5 ezyang]: > It's pretty standard, yes (we implement for handling the global block pool), but it does mean all of that code would have to be made thread- local. I guess that means even worse performance problems on OS X? Even if it does, it sounds like the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:01:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:01:06 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.a642bcd6cc6c9c53c1f033135a2c9794@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by carter): @tibbe, becaue TLS is slow on OS X currently? (mind you, my understanding is that the other RTS issues go away when building GHC with a REAL GCC, right? I take it thats not the case for this discussion? ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:03:22 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.03a67178d84f07921ef288fe62ad05fc@haskell.org> #5599: msys has bad Unicode support -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * owner: igloo => * difficulty: => Unknown * status: closed => new * resolution: fixed => Comment: I was running the validate testsuite on MSYS2, and it looks like in this case, these two tests pass. So maybe we should have a further test for MSYS versus MSYS2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:06:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:06:01 -0000 Subject: [GHC] #5599: msys has bad Unicode support In-Reply-To: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> References: <046.3f625e98390ad242d829f3e1c223a6bd@haskell.org> Message-ID: <061.8a372f22c7c729eb53d53658497094b3@haskell.org> #5599: msys has bad Unicode support -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): It also looks like T4006 is in a similar boat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:28:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:28:19 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.e475cd36993150a3d54327a75276a8d0@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"40ce20357fb6266471a53cec7de0a810a3070f36/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40ce20357fb6266471a53cec7de0a810a3070f36" Fix #8698 by properly handling long section names and reenabling .ctors handling Our old function for searching for sections could only deal with section names that were eight bytes or shorter; this patch adds support for long section names. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:28:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:28:47 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.daace357ebb995cac0ef984e574d6ac2@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Changes (by ezyang): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:36:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:36:59 -0000 Subject: [GHC] #8737: T5975a fails when using official Windows Python distribution Message-ID: <045.57242a86fed659d26a61e69d98d0cd01@haskell.org> #8737: T5975a fails when using official Windows Python distribution --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test | Version: 7.8.1-rc1 Suite | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: T5975a Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Using the official MSYS2 instructions: {{{ =====> T5975a(ghci) 988 of 3859 [0, 0, 0] cd ./ghci/scripts && touch f??b?r1.hs cd ./ghci/scripts && HC='C:/msys64/home/Administrator/ghc/inplace/bin/ghc- stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history ' 'C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history T5975a.run.stdout 2>T5975a.run.stderr Actual stderr output differs from expected: --- /dev/null 2014-02-05 03:11:58.000000000 +0000 +++ ./ghci/scripts/T5975a.run.stderr 2014-02-05 03:11:58.103200000 +0000 @@ -0,0 +1,2 @@ + +: can't find file: f??b?r1.hs *** unexpected failure for T5975a(ghci) }}} When we disable the cleanup hook and look at the directory listing, we see that Python has created the following file: "f????b??r1.hs". I think this is some sort of encoding problem, since we see similar behavior when running a simple Python script: {{{ #coding=utf-8 open('f??b?r1.hs', 'w').write("") }}} Maybe this bug shows up in MSYS as well, but I haven't checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:39:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:39:18 -0000 Subject: [GHC] #8737: T5975a fails when using official Windows Python distribution In-Reply-To: <045.57242a86fed659d26a61e69d98d0cd01@haskell.org> References: <045.57242a86fed659d26a61e69d98d0cd01@haskell.org> Message-ID: <060.4d0af3316dbd4e8e29bc030cc9fd805b@haskell.org> #8737: T5975a fails when using official Windows Python distribution ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Test Suite | Version: Resolution: duplicate | 7.8.1-rc1 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: T5975a | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: 7305 | Related Tickets: ------------------------------------------------+-------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 7305 Comment: Oops, looks like Simon Marlow already reported this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:41:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:41:18 -0000 Subject: [GHC] #7305: T5975a is broken on Windows In-Reply-To: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> References: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> Message-ID: <062.880f721403c426a6dc9dee9324831feb@haskell.org> #7305: T5975a is broken on Windows -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * blocking: 8737 => Comment: When using an MSYS2 build, the cause of the problem seems clearer: the Python test script is creating a file with the wrong name. You can see this by running: {{{ #coding=utf-8 open('f??b?r1.hs', 'w').write("") }}} and then looking at the directory in the file explorer. I don't know what the right way to fix this is though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:44:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:44:29 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.5dc224c2cade452252bb64aa2aee85b5@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): In this case, slowness of TLS is not an issue, because we manually pass around pointers to structs which are known to be per-capability (and can be accessed in an unsynchronized way), so you don't actually need thread- local *state*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 03:57:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 03:57:12 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test Message-ID: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> #8738: msys2 fails cabal01 test --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test | Version: 7.8.1-rc1 Suite | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: cabal01 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ msys2 with 64-bit GHC has an odd failure here: {{{ =====> cabal01(normal) 81 of 3859 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA =--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable- shared cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2014-02-02 04:48:11.233000000 +0000 +++ ./cabal/cabal01/cabal01.run.stdout 2014-02-05 03:09:28.998400000 +0000 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 install2: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 dist: build package.conf.inplace }}} This is because setup is selecting this directory as the location for the installation: {{{ /inplace/bin/ghc-pkg.exe' --package- db=local.db'C:/msys64/home/Administrator/ghc Configuring test-1.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. Dependency base >=1.0: using base-4.7.0.0 "C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe" "--info" Using Cabal-1.18.1.3 compiled by ghc-7.9 Using compiler: ghc-7.9.20140205 Using install prefix: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install Binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Libraries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Private binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\test-1.0 Data files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Documentation installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\doc\x86_64 -windows-ghc-7.9.20140205\test-1.0 Configuration files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\etc Administrator at EZYANG-W2K8 ~/ghc/testsuite/tests/cabal/cabal01 $ ./setup.exe copy -v directory dist\doc\html\test does exist: False Installing library in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing executable(s) in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Warning: The directory C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin is not in the system search path. creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B Installing dist\build\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\A.hi Installing dist\build\B\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B\A.hi creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\libHStest-1.0.a to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\libHStest-1.0.a creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\HStest-1.0.o to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\HStest-1.0.o creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testA\testA.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testB\testB.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe }}} Perhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 06:10:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 06:10:15 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.4182d6a35fab48fec8ab771fc1ff26f3@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Comment (by awson): At 4323: {{{errorBelch("%" PATH_FMT ": can't find section named: ", oc->fileName);}}} named as what? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 08:10:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 08:10:34 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.4da30b6048d8a8ee3fe746c3f7d5a89e@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Comment (by ezyang): It's printed using `printName` the next line. There might be a better way of doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 08:19:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 08:19:09 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.3b49577392ebfc75bffe5c3923d5a46b@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Comment (by awson): Ah, sorry, I've overlooked this. `printName` uses `debugBelch` though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 08:42:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 08:42:54 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.7bf9998d35bc9f65e2f5d9e23cffca58@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Comment (by ezyang): Oh, that is not going to work properly then. Hm, I guess we could parametrize printName with which belch function to use? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 12:59:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 12:59:42 -0000 Subject: [GHC] #8738: msys2 fails cabal01 test In-Reply-To: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> References: <045.e5b4b4cce287d04bf2354c1ec173d94b@haskell.org> Message-ID: <060.51c09f27345d172ed7eeed41a378d667@haskell.org> #8738: msys2 fails cabal01 test ------------------------------------------------+-------------------------- Reporter: ezyang | Owner: refold Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: Resolution: | 7.8.1-rc1 Operating System: Windows | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: cabal01 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by refold): * owner: => refold Comment: > Perhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected? I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 14:30:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 14:30:43 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.e5b6c03c5c9d9149e5173b2493ffa21e@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): I don't really understand why in mighty he couldn't just re-use the same block. I'm kind of surprised that this is a bottleneck, and I think it needs more investigation. We only take the lock for large objects, so typically there's going to be a lot of computation going on per allocation. I suppose if it really is a problem then we could just have a per-thread block pool at the granularity of a megablock to avoid fragmentation issues. We just push the global lock back to the megablock free list. This has the danger that we might have a lot of free blocks owned by one thread that don't get used, though, so we might want to redistribute the free blocks at GC. Things start to get annoyingly complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 14:40:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 14:40:06 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.a2ddf5b098df8f0140273d849646322c@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * owner: simonmar => Comment: Hmm. Isn't it application-specific knowledge that the recv() is going to block? I'm not sure what it is you're proposing that the IO manager should do, could you elaborate? > One argument for why this should work without user interaction, in addition to the standard "it's nice if it just works" argument, is that if we didn't use the I/O manager but instead normal blocking syscalls, we'd end up with better behavior in this case. If you used blocking syscalls you'd end up with much worse scaling, that's why we have the IO manager, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 14:44:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 14:44:11 -0000 Subject: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous In-Reply-To: <047.209fb2dee42076110a1739ebc55e4ab4@haskell.org> References: <047.209fb2dee42076110a1739ebc55e4ab4@haskell.org> Message-ID: <062.63f12195a49bca9776922c6457453250@haskell.org> #5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 14:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 14:54:10 -0000 Subject: [GHC] #8732: Global big object heap allocator lock causes contention In-Reply-To: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> References: <044.a362245e1caab544f39c02e92f1f1660@haskell.org> Message-ID: <059.870f726653d80e4252d9d25fe4cf38a6@haskell.org> #8732: Global big object heap allocator lock causes contention --------------------------------------------+------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): It's even harder than that, because a block can be allocated by one thread and freed by another thread, so we lose block coalescing, even if it can be made to work safely. So I suggest if we want to do anything at all here, we just do the really simple thing: we allocate a chunk of contiguous memory, keep it in the capability, and use that to satisfy large block requests if it's large enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 15:37:11 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 15:37:11 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.7721712f2b16478bbc4342ac118deb40@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:10 simonmar]: > If you used blocking syscalls you'd end up with much worse scaling, that's why we have the IO manager, no? Sure. I guess I'm saying that the I/O manager makes some things better and some things worse. This bug is a bit nebulous. I'm not sure there's a good solution without involving the user. However, we should at least think about it as this will come up in more or less every server we write. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 17:14:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 17:14:05 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks Message-ID: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> #8739: ($) returning kind # no longer type checks ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given: {{{ {-# LANGUAGE MagicHash #-} module InnerLoop(go) where import GHC.Exts go :: () -> Int# go () = go $ () }}} This type checks fine on GHC 7.2.3, and I have a similar version that works fine with 7.4 and 7.6. However, with GHC 7.8.20140130, I get: {{{ InnerLoop.hs:5:9: Kind incompatibility when matching types: s0 :: * Int# :: # In the expression: go $ () In an equation for `go': go () = go $ () }}} This code was reduced from [http://neilmitchell.blogspot.co.uk/2014/01 /optimising-haskell-for-tight-inner-loop.html this blog post], and code which triggers a similar bug can be [https://github.com/ndmitchell/shake/issues/94 found in Shake]. I know {{{$}}} has special type checking rules, were they removed or changed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 17:41:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 17:41:24 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.9f819c4dbb8c2d3042798ef1b0863117@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by jwlato): * cc: jwlato@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 20:44:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 20:44:03 -0000 Subject: [GHC] #8740: Code conditionally compiles Message-ID: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> #8740: Code conditionally compiles ----------------------------+---------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} data Abstract data Reified data Player data Elect p a where ElectRefAsTypeOf :: Int -> Elect Abstract a -> Elect Abstract a ElectHandle :: a -> Elect Reified a Controller :: Elect Abstract Player Owner :: Elect Abstract Player You :: Elect Abstract Player deriving instance (Eq a) => Eq (Elect p a) deriving instance (Ord a) => Ord (Elect p a) }}} As is, the above code fails to compile. But if I move `ElectRefAsTypeOf` to be the last constructor for the GADT, the code does compile. If I remove one of the `Elect Abstract Player` constructors, the code still won't compile even if the `ElectRefAsTypeOf` is moved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 20:54:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 20:54:02 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles (was: Code conditionally compiles) In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.b3f13ea4530376752063d41e49f2c9f6@haskell.org> #8740: Deriving instance conditionally compiles ----------------------------------------------+---------------------------- Reporter: thomaseding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 21:51:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 21:51:03 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.e7e23a1a1d0cf969f769ed5bf606b333@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): So here are three approaches that come to mind for the original Template Haskell issue. 1. When dynamically loading module M from package P, just link together all the dependencies of M in package P, regardless of whether they have been loaded already, and hope that loading two copies of a dependency won't cause any problems. Unclear whether the latter is the case. 2. After building and loading the shared library of dependencies and running Template Haskell for a module, unload the shared library. (Or, lazily unload it only when we need to load more modules that have intra- package dependencies on modules we have loaded already.) I don't know how difficult this is, but I understand that unloading shared libraries is supposed to basically work, so perhaps it's not hard. 3. Build a separate "flavor" of object file `.really_dyn_o` that uses dynamic references even to symbols in the same package, so we can freely dynamically load individual modules. These are needed only while building a package that uses Template Haskell; once the package is completely built they can be thrown away. This is the most obviously correct option IMO, but it might impose a pretty high build time cost. I think option 2 is best, unless it turns out to be a lot harder than I anticipate, with option 3 my second choice. There's a closely related issue in ghci with incrementally loading modules in the "main" (i.e., no) package, which is what the test case I attached actually demonstrates. In this setting, unloading old modules so that we can reload them linked against new ones seems less reasonable, since we might be resetting global state I guess. So here I think option 3 is best. It would be very easy to implement: simply disallow static linking to any symbol in the "main" package. (Is there a good reason to build `.dyn_o` files for an executable in the first place?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 21:54:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 21:54:43 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem Message-ID: <042.41e003931db44554a93be772501d4d70@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: POSIX Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Alain O'Dea reports in an [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078 email] that: {{{ Prelude> System.Directory.getPermissions "/usr/bin/ld" *** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system) }}} > That seems wrong. > > An `access(*, W_OK)` syscall by design should return `EROFS` on a read- only file system by specification. > > This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions "/usr/bin/ld"`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 22:12:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 22:12:50 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.29912428c2b93341493e0dd5dfb08616@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nh2): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 22:29:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 22:29:31 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.858d9d38cd53d0d1db8dea44288a70e4@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): I would be interested to know what the source of the overhead is when making the recvfrom call that fails. I.e. is due to having more syscalls or from invoking the IO manager (Haskell-land) code to register the callback (requires taking an MVar, etc). If it is the sys call, then we would have to do something like you describe where you avoid making the recvfrom call right after the send. If, OTOH it is IO manager overhead, then we may be able to fix it by streamlining the IO manager. E.g. we could try to avoid taking any MVars to register callbacks. We've also talked about integrating the IO manager more closely with the threaded RTS and writing it in C. I think we could easily reduce the overhead if we go down that route. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 22:30:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 22:30:26 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.57e1ed103d9919ee551508d8f58ec221@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by AndreasVoellmy): * cc: andreas.voellmy@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 22:46:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 22:46:18 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.dc99cc7dc5536005fd50c0f708f90186@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: new Priority: high | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by AlainODea): * owner: => AlainODea * difficulty: Unknown => Easy (less than 1 hour) * component: libraries/directory => libraries/unix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 23:29:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 23:29:03 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.3ae0f96d92ff057a796fea6b1aa9125e@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): Hmm, option 2 won't interact very well with the parallel upsweep... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 5 23:57:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Feb 2014 23:57:39 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.8717e00b62ee219c412dcba8c88e052d@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Another measurement of compile time changes, this time of running `make` in a clean an configured GHC tree: changes from 31m34 to 32m7 an increase of 1,75%, confirming the numbers measured in nofib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 00:52:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 00:52:43 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.343ff99f0f0e49037722d8c7c49a0e8e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by George): No idea but as we seem to have different versions of ar I assuming that we are on different versions of Mac OS or Xcode. I am on OS 10.9.1 and Xcode 5.0.2. {{{ ls -l /usr/bin/ar -rwxr-xr-x 1 root wheel 14224 Oct 27 17:59 /usr/bin/ar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 01:08:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 01:08:16 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.e9c0621a474c9407df7678fe680bace1@haskell.org> #8735: hpc doesn't work on Mac ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by George): OS 10.9.1 xcode 5.0.2 {{{ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","@ArSupportsAtFile@") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.20140130") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.8.20140130") ,("Global Package DB","/usr/local/lib/ghc-7.8.20140130/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 01:14:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 01:14:40 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.aabeec3ab644c7e5e69a3fe2856a3580@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: patch Priority: high | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by AlainODea): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 01:17:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 01:17:49 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.c61e9fb252be9c89301b823bb14af794@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Documentation | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by George): Thanks, makes sense. Can you confirm my understanding? to load compiled object files into ghci users must compile with the -dynamic-too option. Once bug #8736 is fixed :load will load a compiled object file into ghci. If so then the release note might say: {{{ On Linux, FreeBSD and Mac OS X, GHCi now uses the system dynamic linker by default, instead of its built in (static) object linker. This is more robust cross-platform, and fixes many long-standing bugs (for example: constructors and destructors, weak symbols, etc work correctly, and several edge cases in the RTS are fixed.) As a result of this, GHCi (and Template Haskell) must now load dynamic object files, not static ones. To get dynamic object files, you must compile with the new compilation flag, -dynamic-too, which causes GHC to emit both static and dynamic object files. GHC itself still defaults to static linking. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 01:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 01:40:05 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.d0abaac970aa336d75b2d078afb8f4e4@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:12 AndreasVoellmy]: > I would be interested to know what the source of the overhead is when making the recvfrom call that fails. I.e. is due to having more syscalls or from invoking the IO manager (Haskell-land) code to register the callback (requires taking an MVar, etc). Good question. I have a theory that the `MVar` overheads might be hurting us and integrating the I/O manager with the scheduler could allow us to get around that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 02:04:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 02:04:43 -0000 Subject: [GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.b4e951abbfc67ae0f7a918d3546f7808@haskell.org> #8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * version: 7.6.3 => 7.8.1-rc1 Comment: Same problem on 7.8.1-rc1. {{{ ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 02:09:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 02:09:22 -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.f9031fe4c24a01af34010e177c56c5ae@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 03:47:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 03:47:16 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.9a8a0635ab4b53c526095fc62f7554c4@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 04:45:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 04:45:45 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.87d26c525ba49e73b16aa69b17c58518@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by carter): I'll add more of my system information shortly (just got off a plane. ). But the biggest difference is I'm using a real GCC. AND my build of ghc was built with it. Your GCC is actually clang. I'm on a very up to date OS X 10.9 machine too. I'll confirm that shortly though. The fact that you have something like @ArSupportsAtFile@ being passed to AR makes me think that the build of ghc went wrong. OR perhaps there's a problem with how clang works as an assembler on OS X? ILL do a clang build of the RC myself to try to replicate this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 04:56:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 04:56:02 -0000 Subject: [GHC] #5476: Cap memory usage for one thread without disrupting other threads In-Reply-To: <048.f4782c6615e970e4c0ac7ccff4280564@haskell.org> References: <048.f4782c6615e970e4c0ac7ccff4280564@haskell.org> Message-ID: <063.0084f96c675500f73c257b5e8e098375@haskell.org> #5476: Cap memory usage for one thread without disrupting other threads -------------------------------------+------------------------------------ Reporter: joeyadams | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * cc: simonmar (added) * difficulty: => Unknown Comment: We have an implementation of space resource limits here http://ezyang.com/rlimits.html , but there will be some engineering difficulties getting this branch properly merged into GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 05:00:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 05:00:58 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.7b9663a880c10dc7f776c24d97296ed8@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by carter): Crazy theory: what version of the gmp dylib do you have? I'm pretty sure I'm using s recent gmp built via brew. Could it be that you're using the apple libgmp dylib and you're tripping a bug there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 07:52:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 07:52:43 -0000 Subject: [GHC] #8545: Reorganize Git repositories In-Reply-To: <042.ff58f710763777250f3a6776932361cb@haskell.org> References: <042.ff58f710763777250f3a6776932361cb@haskell.org> Message-ID: <057.3a9b957e7c34059c77b169107e5d5506@haskell.org> #8545: Reorganize Git repositories -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Resolution: | Keywords: git Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8251 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"ad44e47542a822ac3e02cf514b5d2be52880fc95/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ad44e47542a822ac3e02cf514b5d2be52880fc95" Switch to relative URLs in .gitmodules Previously, the `http://`-protocol part was hardcoded in the URLs, causing the initial clone process to fall back to `http://` even when the ghc.git repo was cloned via one of the other 3 supported transport protocols. This is slightly related to #8545, as it will make it possible to e.g. git clone --recursive git://git.haskell.org/ghc and clone ghc.git including all submodules in one go (i.e. w/o `sync- all`), and w/o falling back to a different (hardwired) Git transport protocol for the submodules. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 08:07:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 08:07:30 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap Message-ID: <047.b2af75ea313cb91018311595681f61c8@haskell.org> #8742: Reuse scavenge_small_bitmap ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 08:17:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 08:17:40 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.31fc5e18bbfa7b8f758c39765b7130e3@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: task | Status: patch Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 09:09:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 09:09:13 -0000 Subject: [GHC] #8725: make DESTDIR=... install broken In-Reply-To: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> References: <046.8a9f647d92bb798f75143ee1d2ebdcd8@haskell.org> Message-ID: <061.ae30ca549037edb1419e9ac89cd46374@haskell.org> #8725: make DESTDIR=... install broken ----------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: I think the right solution is to ignore this and expect people not to mess with `ghclibexecdir`. Thus closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 09:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 09:11:27 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.7b43c6e19f77e8e5c3170762af303f43@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:14 tibbe]: > Good question. I have a theory that the `MVar` overheads might be hurting us and integrating the I/O manager with the scheduler could allow us to get around that. Just wondering, would integration with the scheduler simplify implementing (soft) timeouts, like e.g. providing {{{#!hs threadWaitReadWithTimeout, threadWaitWriteWithTimeout :: Fd -> Int -> IO Bool }}} directly in the I/O manager? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 09:15:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 09:15:14 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.1dffef7c91463a914e2eae7eb5df321c@haskell.org> #8735: hpc doesn't work on Mac ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by nomeata): This is not specific to mac; the problem is that a dynamically linked file, which finds its libraries via rpath, is installed into the system- wide bin. I believe you need a patch like {{{ Index: ghc-7.9.20140130/utils/hpc/ghc.mk =================================================================== --- ghc-7.9.20140130.orig/utils/hpc/ghc.mk 2014-01-31 17:28:32.000000000 +0000 +++ ghc-7.9.20140130/utils/hpc/ghc.mk 2014-02-04 23:15:53.000000000 +0000 @@ -15,4 +15,7 @@ utils/hpc_dist-install_INSTALL = YES utils/hpc_dist-install_INSTALL_INPLACE = YES utils/hpc_dist-install_PROGNAME = hpc +utils/hpc_dist-install_SHELL_WRAPPER = YES +utils/hpc_dist-install_INSTALL_SHELL_WRAPPER_NAME = hpc + $(eval $(call build-prog,utils/hpc,dist-install,1)) Index: ghc-7.9.20140130/utils/hpc/hpc.wrapper =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ ghc-7.9.20140130/utils/hpc/hpc.wrapper 2014-02-04 23:17:49.000000000 +0000 @@ -0,0 +1,2 @@ +#!/bin/sh +exec "$executablename" ${1+"$@"} }}} or something nicer. (from http://anonscm.debian.org/darcs/pkg-haskell/ghc/patches/hpc-wrapper ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 12:56:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 12:56:47 -0000 Subject: [GHC] #8735: hpc doesn't work on Mac In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.6785102c9f80ffac81b9a9f38461cd7b@haskell.org> #8735: hpc doesn't work on Mac ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Changes (by George): * priority: normal => high Comment: Thanks very much. I assume we need a working hpc for 7.8.1 thus making the priority high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 11:16:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 11:16:14 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.09ddf7879b76ca40f3373d38421c6fef@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: patch Priority: high | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ecc92abad017cf12d8eb83509d4d57ae14ad47f9/unix"]: {{{ #!CommitTicketReference repository="unix" revision="ecc92abad017cf12d8eb83509d4d57ae14ad47f9" Handle EROFS/ETXTBSY as permission denied in `fileAccess` (re #8741) This extends `System.Posix.Files.`access` to map EROFS & ETXTBSY to mean permission denied just like EACCESS. Based on a patch by Alain O'Dea and comments by Duncan Coutts Authored-by: Alain O'Dea Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 10:35:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 10:35:45 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.47d239505032a9233e454404151747e3@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: patch Priority: high | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by duncan): So the patch looks ok. I think I would also add ETXTBSY as another alternative, i.e. {{{ (err == eACCES || err == eROFS || err == eTXTBSY) }}} Since according to `access(2)` {{{ ETXTBSY Write access was requested to an executable which is being exe? cuted. }}} and `open(2)`: {{{ ETXTBSY pathname refers to an executable image which is currently being executed and write access was requested. }}} So the patch on its own is fine, but looking at `System.Directory.getPermissions` leaves me aghast: {{{ read_ok <- Posix.fileAccess name True False False write_ok <- Posix.fileAccess name False True False exec_ok <- Posix.fileAccess name False False True stat <- Posix.getFileStatus name }}} Four! Four? Four calls to stat? (`access()` is just a C lib function that calls `stat()`.) Surely we can do better than that? One call to stat should be enough. Also, `access` doesn't do quite what we want. What we want to know is "if I tried to read/write/exec/traverse this file/dir, would it work?". But access answerss a subtly different question: {{{ The check is done using the calling process's real UID and GID, rather than the effective IDs as is done when actually attempting an operation (e.g., open(2)) on the file. This allows set-user-ID programs to eas? ily determine the invoking user's authority. }}} Well, that's all very good and useful, but it's not what we want here. So yes, ideally we'd do one stat call and work it all out from there. {{{ stat <- Posix.getFileStatus name let mode = Posix.fileMode stat read_ok = -- bit twiddling on mode using constants like Posix.ownerReadMode write_ok = -- etc exec_ok = -- etc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 14:21:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 14:21:15 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.357b06a51d77b27df7884f7f0a80eaa1@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * milestone: => 7.10.1 Comment: yup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 14:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 14:32:21 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.720c52ac6c49d5a19ca253399dfe67d7@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: simonmar Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): By the way, I found a very similar duplication in `rts/sm/Compact.c`. Would an issue+patch be appreciated for that file as well? Or you can easily find the occurrences yourself if you prefer: {{{ $ your-favorite-grep-tool 'while \(size \> ' ... rts/sm/Compact.c 272: while (size > 0) { 318: while (size > 0) { 398: while (size > 0) { ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 14:34:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 14:34:10 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.fce9efcde71944a25efd70e6e887d625@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: closed request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Closing because it's not clear that there's any benefit to this and the discussion wondered off in a different direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 14:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 14:39:40 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.4e4335b4cd7ccd739661a3a89732355d@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: simonmar => * status: patch => new Comment: Sure. Just update the patch here to include those too. If you could check that the generated code is exactly the same that would be good. I suspect I inlined these things by hand out of paranoia. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 14:50:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 14:50:33 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.08b67154db82890b39e0c5720210493b@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Absolutely, will do! (It will take a day or two tough) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 15:41:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 15:41:36 -0000 Subject: [GHC] #8735: hpc doesn't work on platforms using dynamic linking (was: hpc doesn't work on Mac) In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.fe6d06b59fc94bdb8a584c8eb9ca7989@haskell.org> #8735: hpc doesn't work on platforms using dynamic linking ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 15:43:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 15:43:40 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails (was: build of head on Mac 10.9 with xcode 5 fails with) In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.157dbf0c61a9f5832470e5b99413da1f@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 6 16:33:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Feb 2014 16:33:53 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.9ea638c62e21ce22aa6163e8e6d7ce8f@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): Status update: I have now finished polishing up the initial source-note patches for tracking source code relations throughout the Core and Stg stages: https://github.com/scpmw/ghc/commits/profiling-review2 This is in many ways the most tricky part of the whole endeavour, as it touches pretty much every single pass that does something interesting with Core. It also extends the whole tickish framework a bit, which means cost- centres, HPC ticks and breakpoints have had some of their code rebuilt. On the other hand, it now passes the whole testsuite (minus T4891 and T5435_dyn_asm, which fail on master for me), and I tested that '-g' causes no extra allocations across nofib. I *think* it should be merge-ready for 7.9. Notes for review (Simon?): - I tried to be chatty with the comments and spell out exactly how I understand the properties of tickishs. Some new tickish flags and lots of documentation in `CoreSyn.lhs`. - Given that we now support multiple ticks in the tree at the same time, I had to give `mkTick` a rewrite. - The change to `cheapEqExpr` is a bit awkward, but it was the only cheap way I could think of for making it look through ticks. - Small changes with their own commit are optional changes or refactoring. Next up will the Cmm support, which so far still needs work on the CmmContext replacement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 00:10:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 00:10:00 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large Message-ID: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ----------------------------------+--------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Running ghc git HEAD (reports it's version as 7.9.20140206) and when cabal installing postgresql-simple I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140206 for x86_64-unknown-linux): Prelude.(!!): index too large Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: postgresql-simple-0.4.0.2 failed during the building phase. The exception was: }}} postgresql-simple-0.4.0.2 installs fine with 7.6.3. I'm going to compile 7.8-rc1 and see if the same problem exists there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 03:02:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 03:02:03 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.0a2b94c4c8d48c5cd5e18094056048e6@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by erikd): * priority: normal => highest * milestone: => 7.8.1 Comment: Same problem for 7.8-rc1 on amd64 Linux (Debian Testing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 03:59:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 03:59:34 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac Message-ID: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------+---------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- On a fresh clone of HEAD, building eventually gets me {{{ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc- Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc- Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc- Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc- DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_thr\" -optc- funroll-loops -static -optc-DTHREADED_RTS -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/sm/Evac.c -o rts/dist/build/sm/Evac.thr_o In file included from rts/sm/Evac.c:21:0: rts/sm/GCTDecl.h:71:0: error: thread-local storage not supported for this target }}} I'm on Mac OS 10.8.5, Xcode 4.6.1 (4H512), bootstrapping from 7.6.3, with `BuildFlavour = devel2`. With this report, my build is dead in the water. (Separately, Trac doesn't have an option for reporting a bug in version 7.9!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:12:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:12:05 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe Message-ID: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: Safe | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In GHC 7.8, !GeneralizedNewtypeDeriving (GND) is type-safe, due to the advent of roles. Although GND allows looking through unimported constructors, the notion of abstraction has changed -- for a type to be fully abstract in 7.8, it must not export its constructors, and the roles of all its parameters must be nominal. Thus, it would seem that GND should be Safe; that is, in the Safe Haskell subset. See also #5498. Currently, GND is not considered Safe. Along similar lines, the `Coercible` and `coerce` mechanism could be considered Safe, but there is no way to import these into a Safe module (they are in `GHC.Exts`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:14:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:14:47 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.903cdaae0f27caae036611af5d1846e1@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by goldfire): I have a terrible feeling this one is my fault. (I wrote code using `!!` in !TcIface.) But I can't build HEAD (see #8744) to find out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:21:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:21:00 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.8f83ec2555dded9ae92b371ff2ad4b62@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by rwbarton): I'm trying to massage GHC into giving me a proper stack trace (with `-xc`) but for now I can tell you the exception occurs somewhere inside `WorkWrap.splitFun`. (Which doesn't use `!!` directly, naturally...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:44:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:44:55 -0000 Subject: [GHC] #8746: Crosscompiling Message-ID: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: Crosscompile | Operating System: Linux cross compile failed ncurses | Type of failure: Building GHC setupterm not found | failed Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello! I tried to crosscompile from linux i386 to arm-linux-gnueabihf, but i cant make it happen, because it gives me this weird error while running 'make': {{{ checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... no checking for setupterm in -lncursesw... no checking for setupterm in -lncurses... no checking for setupterm in -lcurses... no configure: error: in '/home/edi/ghc_cross/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See 'config.log' for more details make[2]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make[1]: *** [all_libraries/terminfo] Error 2 make[1]: Leave Directory '/home/edi/ghc_cross/ghc' make: *** [all] Error 2 }}} What have i done: -) Compiled 7.8.0 from github (The log says 'That should have been 7.8.0', i chose 7.8 because i thought it would be more stable for crosscompiling) to my i386 (normal boot, configure, make, make install). This worked fine -) installed newest llvm from svn (LLVM version 3.5svn) -) replaced the libffi-3.0.11.tar.gz in ghc/libffi-tarballs with libffi-3.0.13 -) added this version of mk/build.mk: {{{ SRC_HC_OPTS = -H32m _o -fasm -Rghc-timing GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -DDEBUG -Wall GhcLibHcOpts = -O -fasm -XGenerics GhcLibWays = v dyn SplitObjs = NO Stage1Only = YES }}} -) downloaded the sourcecode of ncurses from http://ftp.de.debian.org/debian/pool/main/n/ncurses/ncurses_5.9.orig.tar.gz and builded it with "./configure arm-linux-gnueabihf --with-gcc=arm-linux- gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/usr/arm-linux- gnueabihf " + "make". afterwards i added the folder to my $PATH -)did "perl boot", "./configure --target=arm-linux-gnueabihf --with-gcc =arm-linux-gnueabihf-gcc --prefix=/usr/arm-linux-gnueabihf" and "make". ./configure worked, but make gives me this weird error. I also tried copying all included files from ncurses to the libraries/terminfo folder, but that also didn't work. I think the mistake is somewhere in the building process, but i'm not exactly sure, so thats why i'm posting this bug. Does anyone have an idea about that? PS: i also made sure that i met the prerequirements mentioned in https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling Greetings, Edi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:51:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:51:06 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.d6e671cfbf7ac7d52a5b9d7977f01f9e@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by rwbarton): Okay, success. {{{ *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: GHC.List.CAF --> evaluated by: WwLib.deepSplitCprType_maybe.con, called from WwLib.mkWWcpr, called from WwLib.mkWwBodies, called from WorkWrap.splitFun, called from WorkWrap.splitFun, called from WorkWrap.tryWW.doSplit, called from WorkWrap.wwBind, called from WorkWrap.wwTopBinds, called from WorkWrap.wwTopBinds, called from UniqSupply.initUs_, called from WorkWrap.wwTopBinds, called from WorkWrap.wwTopBinds, called from SimplCore.doPassDFU, called from ... }}} The offending code is {{{#!haskell deepSplitCprType_maybe fam_envs con_tag ty | let (co, ty1) = topNormaliseType_maybe fam_envs ty `orElse` (mkReflCo Representational ty, ty) , Just (tc, tc_args) <- splitTyConApp_maybe ty1 , isDataTyCon tc , let cons = tyConDataCons tc con = ASSERT( cons `lengthAtLeast` con_tag ) cons !! (con_tag - fIRST_TAG) = Just (con, tc_args, dataConInstArgTys con tc_args, co) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:59:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:59:19 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.d65449145cb0affd45857e95089394d8@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"298a25bdfd02bb591fde2dd0590bd7af81a91b94/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="298a25bdfd02bb591fde2dd0590bd7af81a91b94" Fix __thread detection (#8722) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:59:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:59:19 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.75009af73294fc8505ec970d1e5256de@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"b4eb630c7480bc56c673a463f274aec18e237e8c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4eb630c7480bc56c673a463f274aec18e237e8c" Remove ios_HOST check for GCTDecl.h Following 298a25bdf and #8722 as Peter mentioned, this probably isn't needed anymore. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 04:59:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 04:59:44 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.75c0af28e58b6d68bd748511423db066@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: thoughtpolice Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 05:00:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 05:00:53 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.c6df85c3af04aa94b8bcbb840b79c1d6@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by thoughtpolice): Can you try now? I just pushed 298a25bdf and b4eb630c74 to HEAD which might fix this for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 05:02:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 05:02:42 -0000 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> References: <047.9dd077e0a526e115792cbcdfa56aeafb@haskell.org> Message-ID: <062.aae2860261d09f30340ee9c1d53821a4@haskell.org> #2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * blockedby: 3658 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 05:03:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 05:03:16 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.701832c8e2e7e085eb31f89662fc3c40@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: merge Priority: high | Milestone: Component: libraries/unix | Version: 7.6.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 05:06:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 05:06:08 -0000 Subject: [GHC] #3452: Show type of most recent expression in GHCi In-Reply-To: <042.b310a33072e5824be86a04c5e7b9cf0d@haskell.org> References: <042.b310a33072e5824be86a04c5e7b9cf0d@haskell.org> Message-ID: <057.ec085509c5726bfba6542cb20487b396@haskell.org> #3452: Show type of most recent expression in GHCi -------------------------------------+------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: hvr (added) * status: patch => new Comment: Taking out of 'patch' status as a bit of work/discussion is still needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 06:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 06:46:08 -0000 Subject: [GHC] #7305: T5975a is broken on Windows In-Reply-To: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> References: <047.9f0dc90b5cf8e0afa160ab6e09aa4504@haskell.org> Message-ID: <062.4fa5c0a46d0f36783380474dff2c9e86@haskell.org> #7305: T5975a is broken on Windows -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): It appears that it is not sufficient to just convert the pre_cmd/post_cmd to accept a Unicode string, as this breaks when using `os.system`, because Python attempts to transcode to ASCII. So we should convert everything to use subprocess/spawnv instead (both of which support Unicode), probably by manually invoking the shell we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 07:03:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 07:03:49 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.c4d9b1ccec51d3adc4b9bc15fe67d4ba@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by jstolarek): Another user reports the same problem with GHC 7.8.1-RC1: http://www.haskell.org/pipermail/glasgow-haskell- users/2014-February/024641.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 09:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 09:04:55 -0000 Subject: [GHC] #8747: GHC 7.4.1 ghc: panic! (the 'impossible' happened) Message-ID: <047.5488887d0204a0e2f366e4762e8c6e21@haskell.org> #8747: GHC 7.4.1 ghc: panic! (the 'impossible' happened) ----------------------------------+------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- I was just trying to create the records in the all about monads tutorial and after changing my code to: {{{ import Data.Maybe (Maybe(Nothing,Just)) data Gender = M | F data Sheep = Sheep (Gender) (Maybe Sheep) (Maybe Sheep) deriving (show) main = undefined }}} I got the following error: {{{ *Main> :r [1 of 1] Compiling Main ( Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): nameModule show{tv aD4} }}} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I've attached my entire ghci log for completeness sake. I'm using debian stable and kernel 3.11-0.bpo.2-amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 09:17:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 09:17:00 -0000 Subject: [GHC] #8747: GHC 7.4.1 ghc: panic! (the 'impossible' happened) In-Reply-To: <047.5488887d0204a0e2f366e4762e8c6e21@haskell.org> References: <047.5488887d0204a0e2f366e4762e8c6e21@haskell.org> Message-ID: <062.38d53accc6e735154314d7b5b56278f5@haskell.org> #8747: GHC 7.4.1 ghc: panic! (the 'impossible' happened) -------------------------------+---------------------------------- Reporter: codygman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5961 -------------------------------+---------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate * related: => #5961 Comment: This is a duplicate of #5961 and fixed in GHC 7.6. Make sure you write `deriving (Show)`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 16:11:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 16:11:19 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.4c4fd8930bbbac6056ad40ae3275c527@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Thanks for the debugging, that is very helpful. It is likely a problem caused by the demand analyser ignoring coercions, so sometimes the type do not match up; in that the solution will be to just make the code more forgiving. Will look into it later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 17:19:21 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 17:19:21 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.707482b19b42698a833d6d232fd1b405@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Thanks, I'll find some time to look through these in detail. One question straight off: in the comment on SourceNote (which is good, BTW), you wrote results of annotated code *must* be invariant against changes to all source code *except* the spans referenced in the source notes. But surely the value of an expression depends on the values of its free variables? The statement only seems to be true for closed expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 17:59:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 17:59:22 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.3462f3bf0fc60e6d35eaba9c18b8b37f@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Joachim Breitner ): In [changeset:"c3ff5f29c80680a09c7779aee2535fa64b880cd9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c3ff5f29c80680a09c7779aee2535fa64b880cd9" Add test case for #8743 which only occurs when the instance being compiled is also present from a .hs-boot file. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 17:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 17:59:23 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.234fce18ca364669e18a406e6a693424@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Joachim Breitner ): In [changeset:"312686c172eefb74237c8a61e2cca1b2af7459c1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="312686c172eefb74237c8a61e2cca1b2af7459c1" In deepSplitCprType_maybe, be more forgiving the ConTag may be out of range (e.g. if the type constructor is imported via SOURCE and we don't know any of its data constructors); just return Nothing without complaining in that case. This fixes #8743. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 18:00:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 18:00:10 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.49b6c566656ae4816d5010f4b6a06c25@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by nomeata): * status: new => merge Comment: Test case added and the obvious fix applied; please merge to 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 18:17:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 18:17:52 -0000 Subject: [GHC] #8264: Canonical way to prevent manual instances In-Reply-To: <046.d620ef4b34976b4392a6e87c16348125@haskell.org> References: <046.d620ef4b34976b4392a6e87c16348125@haskell.org> Message-ID: <061.33705d040d2f0b095ea3bdb343bfaaaa@haskell.org> #8264: Canonical way to prevent manual instances --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: This was introduced in 17a868afa169c52d8525a95cbed87b2fc12044c6, (`abstractClasses`, used in `checkValidInstHead`) for `Coercible` only so far. This position is, however, unsuitable for classes that are being derived, as these also have to pass through `checkValidInstHead`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 18:23:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 18:23:55 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.6e9937beb2a64979319256741e819fac@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): Good point. I could claim that I was arguing from the point of view just before evaluating the expression, but this needs clarification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 21:30:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 21:30:52 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.9a89df7d893102e1f7fab661a00f986a@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by goldfire): The build (with your commits) is working on a Mac with a slightly different setup. Will test on the original failing machine this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 7 22:20:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Feb 2014 22:20:32 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.2d1db681de08d4aae0145bf03ee24da4@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * component: Compiler (Parser) => Documentation Comment: Argh. Of course there can't be kind operators, because it would be impossible to parse them. For example, what does `Foo * Bar` mean? Is it `Foo` applied to `*` and `Bar`? Or is it `*` applied to `Foo` and `Bar`? I will document this, but I don't like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 08:24:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 08:24:46 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.d1c3dbccd64257e55043d22a39315fcb@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * milestone: 7.6.2 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 09:11:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 09:11:18 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode Message-ID: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Steps to reproduce: {{{ 0. Pick any platform. I've performed it on amd64, but seen real failures on unreg arches: ia64, ppc64 1. pull sources 2. ./boot 3. ./configure --enable-unregisterised # right, no build.mk 4. make }}} Here we see 2 kinds of bugs at once: 1. threaded RTS misses '''-DNOSMP''' define. Looks like ghc always needs to carry that define (what is the mechanism for it BTW?), it doesn't: {{{ HC [stage 1] compiler/stage2/build/ExtsCompat46.o In file included from /home/slyfox/dev/git/ghc/includes/Stg.h:232:0: 0, from /tmp/ghc6527_0/ghc6527_2.hc:3: /home/slyfox/dev/git/ghc/includes/stg/Regs.h:443:2: error: #error BaseReg must be in a register for THREADED_RTS #error BaseReg must be in a register for THREADED_RTS ^ }}} The implicit declarations are scary as well: {{{ /tmp/ghc1420_0/ghc1420_2.hc: In function 'c7WZ_entry': /tmp/ghc1420_0/ghc1420_2.hc:43:1: warning: implicit declaration of function 'hs_bswap64' [-Wimplicit- function-declaration] _c7X5 = hs_bswap64(*((P_)(R1.w+7))); ^ }}} I naively tried naive approach: {{{ mk/config.mk.in: +# Unregisterised build calls c compiler for every +# .hs file. thus pass it everywhere. +ifneq "$(GhcWithSMP)" "YES" +SRC_HC_OPTS += -optc-DNOSMP +endif }}} but got stage2, which always '''SIGSEGV'''s. Thus it's either incorrect fix or '''UNREG''' is broken. 2. profiling builds (all files with -prof) miss '''enterFunCCS''' declaration: {{{ /tmp/ghc7183_0/ghc7183_1.p_hc: In function 's6Y_entry': /tmp/ghc7183_0/ghc7183_1.p_hc:79:40: error: 'enterFunCCS' undeclared (first use in this function) ghcFunPtr = ((void (*)(void *, void *))enterFunCCS); ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 09:14:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 09:14:41 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi Message-ID: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> #8749: Pattern synonyms crash GHCi ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ ghci -XPatternSynonyms > let pattern P x = x }}} causes a panic. I understand pattern synonyms are currently unsupported in GHCi, but we should give an error message, not a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 09:26:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 09:26:47 -0000 Subject: [GHC] #8750: Invalid identifier generated with Template Haskell not rejected Message-ID: <048.b4360da9d8570bad1f1bddfa9464dc6c@haskell.org> #8750: Invalid identifier generated with Template Haskell not rejected --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I wrote Template Haskell code that generates this declaration: {{{ data (:+Sym1) (a:: Nat) (b :: TyFun Nat Nat) }}} `(:+Sym1)` is not a valid identifier and this declaration fails when I simply put it in a source file and try to compile it. However I get no errors when this definition is generated from Template Haskell. Not sure if this is intended behaviour or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 09:47:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 09:47:55 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.618ec26e8d4c6b5d32db49923fd729c7@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): In addition to '''NOSMP''' '''includes/stg/SMP.h''' also contains references to '''WITHSMP''' {{{ #elif !defined(WITHSMP) }}} Are they the same thing? Looks like '''WITHSMP''' is not set anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 11:04:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 11:04:56 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.92a9ca33c8f7d83cc3dee9091a750d85@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): The real problem seems to me to be the fact that local pattern synonym definitions are not rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 12:50:57 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 12:50:57 -0000 Subject: [GHC] #8735: hpc crashes on platforms using dynamic linking (was: hpc doesn't work on platforms using dynamic linking) In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.439f0e48400df4a08636f4c59058df53@haskell.org> #8735: hpc crashes on platforms using dynamic linking ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 14:21:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 14:21:11 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.de1b67f60396fa3fa99e85178d22289f@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Documentation | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by George): I understand now that compiling with -dynamic allows object files to be loaded into gchi. It would be good to improve doc. Looks like gnu emacs package should be changed to use that. I'll file a bug with them on that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 15:41:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 15:41:59 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.6ead6bc4cbc08ca87799028ab3655c24@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 17:24:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 17:24:36 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci Message-ID: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> #8751: Show parenthesised output of expressions in ghci ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Operator fixity can be a source of bugs (even for experienced users!),[#point1 (1)] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{ ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b ? a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 17:43:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 17:43:50 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.d5caef6f9f8efde415444ecadb8afcb9@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Iceland_jack): * owner: Iceland_jack => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 18:10:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 18:10:40 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.f2356a36fe22669d521a62c0da0d369f@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I have an implementation plan: * Augment `InstBindings` with a new field `ib_extensions`, which will be a list of `ExtensionFlag`. * In `tcInstanceMethods`, apply these flags using `setXOptM`. * In the `is_newtype` branch of `genInst`, set `ib_extensions` to `[Opt_ImpredicativeTypes]`. * Elsewhere, set `ib_extensions` to `[]`. Seems quite straightforward once I've examined all the plumbing. Expect a patch in the next few hours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 19:11:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 19:11:02 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.9bd9ba621638e173327ba43d2048a4c1@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"218dead0d85a136b5d5648e4d6c4c9cc9467eb45/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="218dead0d85a136b5d5648e4d6c4c9cc9467eb45" Fix #8706, documenting that type operators are not promoted. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 19:14:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 19:14:47 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.ec1ac43fca98655f8a19f2ecfb87fc46@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 21:41:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 21:41:11 -0000 Subject: [GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute Message-ID: <047.ba20b266365045acfd96ace488f847bb@haskell.org> #8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+--------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: filepath | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- "Combine two paths, if the second path isAbsolute, then it returns the second.? But, the implementation of combine checks if the first character of a path is a path separator, which on Windows is not the same as checking if isAbsolute. This can have counterintuitive results. For example: {{{ import System.FilePath.Windows prop_windows_is_sane :: Bool prop_windows_is_sane = isAbsolute p || ("C:\\STUFF" p /= p) where p = "\\foo\\bar" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 23:09:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 23:09:31 -0000 Subject: [GHC] #8753: Import constructor but not the data type Message-ID: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> #8753: Import constructor but not the data type ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (A) defines a parametrized data type (D a) which I want to use in my code (B) in instantiated form (D Int) but with the same name (D). I want to pattern match against inhabitants of type D, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "D". module A where data D a = D a module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 23:22:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 23:22:59 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.6ac770d578a8e4e65e196118c88e94df@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): Andreas, I think pattern synonyms cover this need. Have you tried them out yet? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 8 23:45:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Feb 2014 23:45:59 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.5faebfb9bfa316e4690e1d80ab6a6047@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by MtnViewMark): I tried building last night with ghc-7.8 tag with the those two patches cherry picked on top. It worked! Mac OS X 10.8.5 w/Xcode 4.5.2 After I cherry picked, I had to do: {{{ make maintainer-clean ./boot ./configure make }}} I'm never sure if that is the right sequence after a pull like this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 00:47:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 00:47:39 -0000 Subject: [GHC] #8734: 7.8.1 rc1 ghci won't load compiled files In-Reply-To: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> References: <045.65b677cc3e6f08e318e38de963f1b778@haskell.org> Message-ID: <060.ad1107d68fd78e14c1e067131d2a4fef@haskell.org> #8734: 7.8.1 rc1 ghci won't load compiled files ------------------------------------------------+-------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Documentation | Version: Resolution: invalid | 7.8.1-rc1 Operating System: MacOS X | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by George): gnu emacs haskell package works fine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 00:52:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 00:52:28 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes Message-ID: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> #8754: :set +s always says space usage is 0 bytes ------------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- :set +s always says space usage is 0 bytes {{{ ghci GHCi, version 7.8.20140130:... ... sumOfPrimes2 40000000 25 1677366278943 it :: Int (14.84 secs, 0 bytes) }}} setting to high as this is a regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 01:16:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 01:16:56 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.ea7f21f90b1dc015525af1e87eade432@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by carter): i've also had this problem with my independent mac build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 02:23:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 02:23:15 -0000 Subject: [GHC] #8755: Happy parser file compilation causes panic Message-ID: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> #8755: Happy parser file compilation causes panic ----------------------------------+--------------------------------------- Reporter: wting | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Sorry I can't be more descriptive, but I'm not exactly sure what's causing the compile time crash. I can compile it on GHC 7.4.1, but it crashes for GHC 7.6.3. {{{ ??ting at noa ~/panic ?python-2.7.3? ?master? ??? ghc DeclareParse.hs [1 of 4] Compiling Base ( Base.hs, Base.o ) [2 of 4] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 4] Compiling Declare ( Declare.hs, Declare.o ) [4 of 4] Compiling DeclareParse ( DeclareParse.hs, DeclareParse.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Prelude.head: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've uploaded all the files here to check out: https://gist.github.com/wting/a6787a3f50ee41dda611 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 03:01:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 03:01:25 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.06e4682cc7577830e28628825d2c81e4@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by goldfire): * status: new => merge Comment: Yes, things worked for me as well. I'll close the ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 03:08:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 03:08:26 -0000 Subject: [GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac Message-ID: <047.9ca2116412c11f6c3e9b82c18e16195a@haskell.org> #8756: Test case concurrent/should_run/T5611 fails on Mac ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- On a fresh check out, test case concurrent/should_run/T5611 fails: {{{ Actual stderr output differs from expected: --- ./T5611.stderr 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stderr 2014-02-08 22:00:06.000000000 -0500 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) Actual stdout output differs from expected: --- ./T5611.stdout 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stdout 2014-02-08 22:00:06.000000000 -0500 @@ -1,2 +1,3 @@ child: Sleeping +child: Done waiting parent: Done throwing exception *** unexpected failure for T5611(normal) }}} I'm on Mac OS 10.8.5 with Xcode 4.6.1 (4H512). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 03:11:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 03:11:45 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.31dede8f015215014ebaf55bffbd42af@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"674c969c240632da70ed2928fa30c20a9a52e5dc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="674c969c240632da70ed2928fa30c20a9a52e5dc" Fix #8631. This patch allows turning on ImpredicativeTypes while type-checking the code generated by GeneralizedNewtypeDeriving. It does this by adding a field ib_extensions to InstBindings, informing the type-checker what extensions should be enabled while type-checking the instance. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 03:12:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 03:12:53 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.4e9359d7fafee3ea9fa4797da47bf832@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => merge Comment: Please merge this into 7.8 -- this bug would annoy users if it stays around. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 03:31:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 03:31:05 -0000 Subject: [GHC] #8755: Happy parser file compilation causes panic In-Reply-To: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> References: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> Message-ID: <059.b8ab7d2356e9f4be562daa5633d55650@haskell.org> #8755: Happy parser file compilation causes panic ---------------------------------------+---------------------------------- Reporter: wting | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by wting): Sorry, this also fails on 7.4.1: {{{ ??ting at sloth ~/code/cs345 ?python-2.7.3? ?hw2? ??? ghc DeclareParse.hs [1 of 4] Compiling Base ( Base.hs, Base.o ) [2 of 4] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 4] Compiling Declare ( Declare.hs, Declare.o ) [4 of 4] Compiling DeclareParse ( DeclareParse.hs, DeclareParse.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): Prelude.head: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm going to try and investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 04:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 04:18:58 -0000 Subject: [GHC] #8755: Happy parser file compilation causes panic In-Reply-To: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> References: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> Message-ID: <059.07cc663f5ea82f718719ca7a25c1c79d@haskell.org> #8755: Happy parser file compilation causes panic ---------------------------------------+---------------------------------- Reporter: wting | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This seems to be fixed in 7.8: {{{ 23:18:03 ~/temp/bug> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.20140130 23:18:06 ~/temp/bug> ghc DeclareParse.hs [1 of 4] Compiling Base ( Base.hs, Base.o ) [2 of 4] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 4] Compiling Declare ( Declare.hs, Declare.o ) [4 of 4] Compiling DeclareParse ( DeclareParse.hs, DeclareParse.o ) DeclareParse.hs:177:11: Not in scope: data constructor ?Subtract? DeclareParse.hs:193:11: Not in scope: data constructor ?Multiply? DeclareParse.hs:202:11: Not in scope: data constructor ?Divide? }}} For the record, I was able to produce this with 7.6.3. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 05:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 05:00:03 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.f988d155646e91c07db36b55faeb4923@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I think i was hit by this when I was trying out LLVM-General on 7.8 RC, https://github.com/bscarlet/llvm-general/issues/83#issuecomment-34557918 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 05:11:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 05:11:48 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.66a558334bc3c658dccf143bb79f34dc@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): When you say simplify, what are you comparing to? Is there some implementation of those functions that you are thinking of? Maybe you mean that those functions are implemented in a way similar to the`timeout :: Int -> IO a -> IO (Maybe a)` function in `System.Timeout`. I haven't measured the performance of `timeout` but I imagine it isn't very good, since it forks a new thread in each call. We do have a couple new functions in 7.8 that might allow us to provide a more efficient implementation than something like`timeout` . In 7.8, we have these functions: `threadWaitReadSTM :: Fd -> IO (STM (), IO ())` `threadWaitWriteSTM :: Fd -> IO (STM (), IO ())` They return an STM action that completes whenever the given file is ready to read (or write). Then we can use it in combination with `registerDelay :: Int -> IO (TVar Bool)` to wait on both the file and the timer without spawning a new thread. It would be something like this: {{{#!haskell threadWaitReadWithTimeout :: Fd -> Int -> IO Bool threadWaitReadWithTimeout fd n = do { (ready, _) <- threadWaitReadSTM fd; alarm <- registerDelay n; atomically ((ready >> return True)`orElse` (readTVar alarm >>= check >> return False)) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 08:24:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 08:24:41 -0000 Subject: [GHC] #8755: Happy parser file compilation causes panic In-Reply-To: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> References: <044.7b74e0b5a3216dd68bbdf9b57739fd6d@haskell.org> Message-ID: <059.88dabe52241b6de913b43ed49a72304b@haskell.org> #8755: Happy parser file compilation causes panic ---------------------------------------+---------------------------------- Reporter: wting | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by monoidal): For the record: it's bug #7882. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 08:56:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 08:56:39 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.22d4e0e560ffd00d320b55cdb76babb9@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:16 AndreasVoellmy]: > When you say simplify, what are you comparing to? Is there some implementation of those functions that you are thinking of? Your suggestion of using the new `threadWait*STM` functions seems to be already an improvement over the naive `timeout`+`threadWait{Read,Write}` approach. I was originally thinking of a more low-level approach: Since `epoll`/`select` and similar OS sys-calls take a `timeout`-argument, that argument would be set according to the earliest due pending `threadWait*WithTimeout` calls when the need arises to actually call `epoll` to wait for new I/O events. Or does this implicitly happen anyway when using `registerDelay` which goes through the `TimeManager`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:00:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:00:22 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.e18ce22d364d05bd76aff822a7cd3ce8@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by hvr): Replying to [ticket:8754 George]: > setting to high as this is a regression ...are you saying, this worked in 7.6.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:18:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:18:02 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations Message-ID: <045.4025838bd3dac3457d42df50984ef416@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Locally-defined pattern synonyms work by accident in GHC and crash GHCi (see #8749), but certainly not by design. It can be confusing because it introduces shadowing to constructor-like names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:20:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:20:15 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.6e4a0fb3a106d27965f036ddd03b3159@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Old description: > How do I import a constructor but not its data type? The constructor > might have the name of a data type which I do not want to bring into > scope. > > Use case: Library (A) defines a parametrized data type (D a) which I > want to use in my code (B) in instantiated form (D Int) but with the same > name (D). I want to pattern match against inhabitants of type D, so I > need the constructor(s) in scope. > > Here is how it could look like if import lists let me specify whether I > want to import a type or a constructor with name "D". > > module A where > > data D a = D a > > module B where > > import A (constructor D) > import qualified A > D = A.D Int > > f :: D -> Int > f (D x) = x > > Haskell has different name spaces for type and constructors, but does not > let the user talk about these name spaces where it matters, namely in > import/export lists. At least I found no documentation instructing me > how to do this. New description: How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (`A`) defines a parametrized data type (`D a`) which I want to use in my code (`B`) in instantiated form (`D Int`) but with the same name (`D`). I want to pattern match against inhabitants of type `D`, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "`D`". {{{#!haskell module A where data D a = D a }}} {{{#!haskell module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x }}} Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Comment (by hvr): (fixed-up wiki markup in ticket description) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:23:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:23:32 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.b5877a91aabed1631596011f0256ff10@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: Blocking: 8749 | -------------------------------------+------------------------------------- Changes (by cactus): * owner: => cactus * blocking: => 8749 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:24:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:24:04 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.29d4354e1881679f5f3b14fc4f1ac6de@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: Blocking: 8749 | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"e0a55415545074bc7a757462624079f54f7785e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e0a55415545074bc7a757462624079f54f7785e2" Issue an error for pattern synonyms defined in a local scope (#8757) This also fixes the internal crash when using pattern synonyms in GHCi (#8749) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:24:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:24:04 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.1d185b248607882f15dbde808d7e77b2@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8757 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Dr. ERDI Gergo ): In [changeset:"e0a55415545074bc7a757462624079f54f7785e2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e0a55415545074bc7a757462624079f54f7785e2" Issue an error for pattern synonyms defined in a local scope (#8757) This also fixes the internal crash when using pattern synonyms in GHCi (#8749) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:24:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:24:44 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.359703f374e82323f7bc180cf54129fa@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: Blocking: 8749 | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:24:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:24:59 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.25eb9a7a51c89fb13416cc076df513a5@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8757 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 09:27:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 09:27:34 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.27f9e8827bf420099b605d41fe68b64c@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: Blocking: 8749 | -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"719108f8d70aa50cdaccf564dbc463445a03988e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="719108f8d70aa50cdaccf564dbc463445a03988e" Add test suite for #8757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 10:12:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 10:12:42 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.f320c210cabf8223ea857761d86cd5e5@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: patsyn/should_fail/local | Blocking: 8749 | -------------------------------------+------------------------------------- Changes (by hvr): * testcase: => patsyn/should_fail/local * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 10:14:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 10:14:26 -0000 Subject: [GHC] #8726: integer-gmp division regression In-Reply-To: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> References: <044.9f3d8c994c0b9ad91a471b20b6e38989@haskell.org> Message-ID: <059.2e748faea1384f5957d4ed2bed8bc419@haskell.org> #8726: integer-gmp division regression ------------------------------------------------+-------------------------- Reporter: erikd | Owner: hvr Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | integer-gmp Test Case: numeric/should_run/T8726 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8647 ------------------------------------------------+-------------------------- Changes (by hvr): * keywords: Integer-gmp => integer-gmp * testcase: => numeric/should_run/T8726 * related: => #8647 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 14:29:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 14:29:14 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.e4e7b04e6757c98e53f4b9e441fe1bcc@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by George): Right, a regression from 7.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 15:49:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 15:49:10 -0000 Subject: [GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes Message-ID: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes -------------------------------------------+------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE RankNTypes #-} module A where class C m where foo :: (forall b. b -> m b) -> c -> m c instance C [] where foo f c = f c }}} and {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype MyList a = Mk [a] deriving C }}} When I compile B.hs, I get {{{ Illegal polymorphic or qualified type: forall b. b -> MyList b Perhaps you intended to use RankNTypes or Rank2Types In an expression type signature: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c In the expression: GHC.Prim.coerce (foo :: (forall (b :: *). b -> [] b) -> c -> [] c) :: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c In an equation for ?foo?: foo = GHC.Prim.coerce (foo :: (forall (b :: *). b -> [] b) -> c -> [] c) :: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c }}} I will fix shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 16:35:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 16:35:35 -0000 Subject: [GHC] #8759: Pattern synonyms and TH Message-ID: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> #8759: Pattern synonyms and TH -----------------------------------+--------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- This file {{{ {-# LANGUAGE PatternSynonyms, TemplateHaskell #-} x = [d|pattern P = ()|] }}} causes a panic. Until TH supports pattern synonyms we should give a sensible error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 16:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 16:48:55 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") (was: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition)) In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.b858b4082957b0c65c4e607b88818c8e@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Changes (by goldfire): * type: bug => feature request Comment: I have to say I like the idea of `-XDysfunctionalDependencies`. An error in functional dependencies can never make a program "go wrong". Why do I claim this? Because the type safety of GHC Haskell is based on the type safety of Core, GHC's internal, typed language.... and functional dependencies don't exist, at all, in Core. So, perhaps functional dependencies can change exactly what Core is produced, but they can only go from one type-safe Core program to another type-safe Core program. I see something like `-XDysfunctionalDependencies` as quite like `-XIncoherentInstances`. These threaten coherence (the notion that the same instance of a class will be used for the same type(s) in different places) but not type safety. The a power user wants to ignore coherence, maybe that's OK. `-XDysfunctionalDependencies` has another nice benefit: it gives users a quick and dirty way to arbitrarily nudge the type inference engine. Currently, one of the tenets of type inference is that it makes no guesses and performs no search. But with `-XDysfunctionalDependencies` users could provide (perhaps incoherent) hints to the type inference engine, which would allow more programs to type check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 16:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 16:55:05 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.9e92bec168ee299953d713e8b9105cbb@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by monoidal): Is this quick fix OK? {{{ diff --git a/compiler/deSugar/DsMeta.hs b/compiler/deSugar/DsMeta.hs index 56fba14..8504892 100644 --- a/compiler/deSugar/DsMeta.hs +++ b/compiler/deSugar/DsMeta.hs @@ -1238,7 +1238,8 @@ rep_bind (L _ (VarBind { var_id = v, var_rhs = e})) ; return (srcLocSpan (getSrcLoc v), ans) } rep_bind (L _ (AbsBinds {})) = panic "rep_bind: AbsBinds" -rep_bind (L _ (PatSynBind {})) = panic "rep_bind: PatSynBind" +rep_bind (L _ (PatSynBind {})) = + sorry "Template Haskell does not yet support pattern synonyms." ----------------------------------------------------------------------------- -- Since everything in a Bind is mutually recursive we need rename all -- all the variables simultaneously. For example: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 17:02:27 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 17:02:27 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.b75b411451fd62f4fa5f5e5bddc54cf0@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Not quite, I'm afraid. * It's better to use `notHandled` than `sorry` in !DsMeta * !TcSplice also has to be updated. The following code also panics: {{{ pattern P = () $( do info <- reify 'P reportWarning (show info) return [] ) }}} I'm happy to put in the fixes. I've got a bunch of others that I've put in today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 17:32:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 17:32:00 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed Message-ID: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> #8760: ghc 7.8: ghc-split not installed --------------------------------+------------------------------------------ Reporter: | Owner: MagnusTherning | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Linux Keywords: | Type of failure: Installing GHC failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ These are the steps I run to build and install (to prepare for packaging): {{{ ./sync-all -r git://git.haskell.org get -b ghc-7.8 ./boot ./configure --prefix=/usr make -j 5 make DESTDIR=/path/to/prepackage/dir install }}} The build itself works fine, the installed binaries work for simple tests like compiling ''hello, world'', starting {{{ghci}}}, etc. However, building '''mtl''' failed with {{{ Configuring mtl-2.1.2... Building mtl-2.1.2... Preprocessing library mtl-2.1.2... [ 1 of 21] Compiling Control.Monad.Writer.Class ( Control/Monad/Write/Class.hs, dist/build/Control/Monad/Writer/Class.o ) ghc: could not execute: /usr/lib/ghc-7.8.0.20140204/ghc-split }}} So it seems ''ghc-split'' isn't installed by {{{make install}}}. It also isn't included in the output of {{{make binary-dist}}}. I've seen this on both ''x86'' and ''x86_64''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 17:35:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 17:35:16 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell Message-ID: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> #8761: Make pattern synonyms work with Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Template Haskell has no support for pattern synonyms. This should be added. Specifically: * Create syntax in `Language.Haskell.TH.Syntax` and corresponding functions in `Language.Haskell.TH.Lib` * Support in !DsMeta for desugaring pattern synonym quotations. See `rep_bind`. * Support in Convert for splicing in pattern synonyms. * Support in !TcSplice for reifying pattern synonyms. See `reifyThing`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 18:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 18:09:59 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types Message-ID: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> #8762: Panic involving unboxed tuples and phantom types ------------------------------------+------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I ran into a bug involving unboxed tuples and the following piece of code is an attempt at isolating the problem: {{{ {-# LANGUAGE UnboxedTuples #-} module Main where type Ty a = Int bug :: Ty a -> (# Ty a, () #) bug ty = (# ty, () #) main = do let (# a, b #) = bug undefined return () }}} It seems that the phantom type is necessary to trigger the bug. The bug is still present in 7.8rc1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 19:19:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 19:19:37 -0000 Subject: [GHC] #8469: GHCi reports out-of-scope type family instances with :info In-Reply-To: <047.6b6cc968421e2300517ed9b70536543b@haskell.org> References: <047.6b6cc968421e2300517ed9b70536543b@haskell.org> Message-ID: <062.a92ed95d50337418b83e86849651d623@haskell.org> #8469: GHCi reports out-of-scope type family instances with :info -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): Should this ticket be marked as fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 20:39:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 20:39:23 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.bea2465305b3267e9b0b5944a408b6ea@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------+------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 20:39:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 20:39:56 -0000 Subject: [GHC] #8469: GHCi reports out-of-scope type family instances with :info In-Reply-To: <047.6b6cc968421e2300517ed9b70536543b@haskell.org> References: <047.6b6cc968421e2300517ed9b70536543b@haskell.org> Message-ID: <062.82fa5cac3f4ab8a3ad96059c22164c94@haskell.org> #8469: GHCi reports out-of-scope type family instances with :info -------------------------------------+------------------------------------ Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Looks like it. Good spot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 22:04:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 22:04:54 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) Message-ID: <042.6416bb310965de24a032dfcecd66fba0@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 22:07:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 22:07:49 -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.42d877beb034403c92ab2997dbd27c98@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 performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nh2): People on #ghc think that it is because the {{{[1.._N]}}} gets floated out as a top-level constant expression: ---- '''nomeata:''' nh2: I?d consider that a bug '''nomeata:''' I believe the problem is that [0..512] does not depend on any local values '''nomeata:''' so it is floated out as a top-level value '''nomeata:''' and there it is not matched by any rules '''thoughtpolice:''' let floating strikes again '''thoughtpolice:''' (well, floating-out being a non-optimization, anyway.) '''Fuuzetsu:''' does this mean that if I use [0 .. 512] twice in a program in different places, it will only be computed once? '''hvr:''' Fuuzetsu: there's a chance, yes '''Fuuzetsu:''' neat '''thoughtpolice:''' well, not so neat. in cases like this you really don't want to float out some things, because it hurts later opportunities to optimize sometimes (e.g. float out a binding that otherwise would have triggered a RULE or fusion, perhaps) '''thoughtpolice:''' unfortunately floating like this is one of the harder things to 'fight against' when you don't want it, from what i've seen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 22:13:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 22:13:59 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.ed8aa8da36a2b72a8b6a6eadbb9f1833@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nh2): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 9 23:55:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Feb 2014 23:55:30 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.925182af292df5fea824a1d0a7ed19da@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by lerkok): * difficulty: => Unknown Comment: Is there any progress on this ticket? Looks like milestone was changed to 7.6.2. I've got 7.6.3 installed, which does not seem to support such deriving instances. Do I need a particular flag to enable this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:01 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.0841674070932b11697895563095f05b@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"02c7135dfce049b53bd38aa35c175302652af507/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="02c7135dfce049b53bd38aa35c175302652af507" Move test case for #8631 to the correct directory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:02 -0000 Subject: [GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes In-Reply-To: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> References: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> Message-ID: <062.0c0ec6f3753ce4bb41a0fafe4251187f@haskell.org> #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes --------------------------------------------+------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Richard Eisenberg ): In [changeset:"8cc398ff8b3f7408327d99347f440693cb204c0a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8cc398ff8b3f7408327d99347f440693cb204c0a" Fix #8758 by assuming RankNTypes when checking GND code. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:02 -0000 Subject: [GHC] #6147: GeneralizedNewtypeDeriving should fail with data families In-Reply-To: <041.fd4661de9a69e677a716fc05040d65b6@haskell.org> References: <041.fd4661de9a69e677a716fc05040d65b6@haskell.org> Message-ID: <056.0f2aaca8fcacf50bcbd2cbd21acf6a53@haskell.org> #6147: GeneralizedNewtypeDeriving should fail with data families ------------------------------------------------+-------------------------- Reporter: rl | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler (Type checker) | Milestone: 7.8.1 Resolution: | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC accepts invalid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Richard Eisenberg ): In [changeset:"9e0c1ae57526bacaca044a7ce5a6491fb6a7cb42/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e0c1ae57526bacaca044a7ce5a6491fb6a7cb42" Test #6147, which was fixed with the roles commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:03 -0000 Subject: [GHC] #7481: Partially promoted data types In-Reply-To: <046.7ab7e0f602ebc7237fac2957bdabcd57@haskell.org> References: <046.7ab7e0f602ebc7237fac2957bdabcd57@haskell.org> Message-ID: <061.8f4300511ef8fccf91cbbc9b8bf58819@haskell.org> #7481: Partially promoted data types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"d1dff94c9a82ffeff0bf92d0f90231a639ade59c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d1dff94c9a82ffeff0bf92d0f90231a639ade59c" Test #7481, which had already been fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:04 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.56c3f18674611d7e7c7d4f9fc70ff81c@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6122efcabe6e08375f69ee19148ba3838c332559/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6122efcabe6e08375f69ee19148ba3838c332559" Fix #8759 by not panicking with TH and patsyns. We should still have pattern synonyms in TH, though. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:04 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.82dadcfae58147f8ad88e43c4c7347e3@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e0dadc87b57ce7f4ec3b72eb52e4abe5a5218f52/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e0dadc87b57ce7f4ec3b72eb52e4abe5a5218f52" Apply changes relative to TH.Pred becoming a TH.Type's synonym (issue #7021) Signed-off-by: Richard Eisenberg }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:05 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.82719cc04bfaa2dc6948459e3f0f06e6@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"182ff9e814a917681b1600b2729c3340801630de/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="182ff9e814a917681b1600b2729c3340801630de" Fix tests due to issue #7021 Signed-off-by: Richard Eisenberg }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:39:05 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.84673ffe4163d8172002b3a91f807047@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8e303d725eba0d6e0f9e52c64da21a0f299fa422/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e303d725eba0d6e0f9e52c64da21a0f299fa422" Refactor previous commit on fixing #7021. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:40:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:40:57 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.56e49c9625550315531d08cce8e16e62@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: deriving/should_compile/T8631 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * testcase: => deriving/should_compile/T8631 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:43:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:43:08 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.173c6902a863ef58ad92b582b72e52b9@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8759 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8761 ---------------------------------------+----------------------------------- Changes (by goldfire): * status: new => merge * testcase: => th/T8759 * related: => #8761 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:44:23 -0000 Subject: [GHC] #6147: GeneralizedNewtypeDeriving should fail with data families In-Reply-To: <041.fd4661de9a69e677a716fc05040d65b6@haskell.org> References: <041.fd4661de9a69e677a716fc05040d65b6@haskell.org> Message-ID: <056.459159421e0a3f38a3e2c4b590a3df1f@haskell.org> #6147: GeneralizedNewtypeDeriving should fail with data families ------------------------------------------------+-------------------------- Reporter: rl | Owner: Type: bug | simonpj Priority: high | Status: closed Component: Compiler (Type checker) | Milestone: 7.8.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC accepts invalid program | Architecture: Test Case: deriving/should_fail/T6147 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by goldfire): * status: new => closed * testcase: => deriving/should_fail/T6147 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:45:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:45:10 -0000 Subject: [GHC] #7481: Partially promoted data types In-Reply-To: <046.7ab7e0f602ebc7237fac2957bdabcd57@haskell.org> References: <046.7ab7e0f602ebc7237fac2957bdabcd57@haskell.org> Message-ID: <061.26657279565ad0358e24911a7ec01f2d@haskell.org> #7481: Partially promoted data types -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: polykinds/T7481 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * testcase: => polykinds/T7481 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:48:21 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.53c4dfeefbd019af959ef4e3778f3d3a@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: closed Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: fixed | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | th/T7021 | Blocking: | -------------------------+------------------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T7021 * resolution: => fixed Comment: I've applied your patches, Yorick. I did a little refactoring at the end, but most of the code stood on its own. Many thanks! I am not recommending this for merging, as it makes a non-trivial change to Template Haskell which will affect many users of TH. I think it's a move in the right direction, but I'm worried with the release candidate already out, that libraries will test against the RC, see that it works, and then be happy. If there's a user-facing change like this in 7.8, people could get caught unaware. If anyone out there (particularly Yorick) feels differently, please advocate your case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 01:49:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 01:49:28 -0000 Subject: [GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes In-Reply-To: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> References: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> Message-ID: <062.131dc7012b11a0edf5330ed2ae182109@haskell.org> #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: merge Component: Compiler (Type checker) | Milestone: Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T8758 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * status: new => merge * testcase: => deriving/should_compile/T8758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 06:45:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 06:45:24 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode In-Reply-To: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> References: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> Message-ID: <060.fdc79a8355b8a3df2f38e12a30753921@haskell.org> #8719: clarify prefetch release notes + remove some deadcode -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): bump :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:15:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:15:23 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.41e9b6d9ca1828cf3d69fb771cb78ac7@haskell.org> #7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Changes (by kgardas): * owner: kgardas => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:23:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:23:48 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). Message-ID: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). --------------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+---------------------------------------- Hello, I've found that (1) GHC's configure attempts to find the GNU sed and once found it's saved into the SED makefile variable. But (2) a lot of GHC's makefiles are using straight 'sed' instead of '$(SED)', i.e found GNU sed. The reason for this bugreport is that on Solaris, the provided sed fails on parsing sed expression in rules-builddependencies.mk. I've solved this issue by fixing 'sed' to '$(SED)' there (patch attached), but the general question is if this should not be fixed everywhere. Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:25:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:25:26 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.04c3de55c8b99658fac45b5077b7ebc8@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by kgardas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:28:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:28:06 -0000 Subject: [GHC] #8765: Add --with-ar and --with-ranlib configure params. Message-ID: <046.3ba6d156e363476a08501abfd52128f1@haskell.org> #8765: Add --with-ar and --with-ranlib configure params. ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've found that I usually miss --with-ar and/or --with-ranlib on Solaris while building GHC. Attached patch fixes that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:28:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:28:39 -0000 Subject: [GHC] #8765: Add --with-ar and --with-ranlib configure params. In-Reply-To: <046.3ba6d156e363476a08501abfd52128f1@haskell.org> References: <046.3ba6d156e363476a08501abfd52128f1@haskell.org> Message-ID: <061.8e560c7d82e24d71a3da15978fa9e28d@haskell.org> #8765: Add --with-ar and --with-ranlib configure params. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kgardas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 08:52:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 08:52:32 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.cf958b2548e10353b34b8a681b2868cf@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: closed Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: fixed | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | th/T7021 | Blocking: | -------------------------+------------------------------------------------- Comment (by carter): Could you summarize what sorts of TH would break with this change? Ie what gets broken vs what gets improved? I assume the changes are localized to this commit https://ghc.haskell.org/trac/ghc/changeset/e0dadc87b57ce7f4ec3b72eb52e4abe5a5218f52/ghc mostly? Could you expand on what sort of TH code might be impacted? (or should i find some time to build current head an test it on some project that currently support 7.8 RC and have heavy TH usage?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 11:33:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 11:33:40 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.11100c3deb7f2966f379fee35e640872@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7346 -------------------------------------+------------------------------------ Changes (by dreixel): * keywords: => Generics * owner: => dreixel * related: => #7346 * milestone: 7.6.2 => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 11:40:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 11:40:51 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.955b2932ebef583c504478d0c0b57641@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7346 -------------------------------------+------------------------------------ Comment (by dreixel): Replying to [comment:22 lerkok]: > Is there any progress on this ticket? Looks like milestone was changed to 7.6.2. I've got 7.6.3 installed, which does not seem to support such deriving instances. Do I need a particular flag to enable this? No, this was not implemented yet. But I like the idea, and I think Simon's specification is good (repeating here): ---- A class can appear in a deriving clause if (and only if) the class has at least one default foo :: type signature, and the class has a default method definition for every method. Thus: {{{ class C1 a where -- NO (no default method) op1 :: a -> a class C2 a where -- NO (non default method signature) op2 :: a -> a op2 x = x class C3 a where -- YES (both are present) op3 :: a -> a default op3 :: Ord a => a -> a op3 x = x>x }}} ---- Only thing left to answer is how to determine the context (in case of standard deriving; in standalone deriving, the user provides the context). For that, I think that Andres's proposal in #7346 sounds reasonable: ---- I propose that if normal deriving is used, GHC uses the same heuristic for figuring out the class context that it uses for Eq in the case of `*`-kinded classes, and for Functor in the case of `* -> *`-kinded classes. That may not be optimal or even wrong. But in such cases, standalone deriving can still be used. ---- If there is no opposition, I'm happy to have a go at implementing this. I agree with [comment:11 dterei] that Haddock and GHCi support would be desirable too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 11:42:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 11:42:01 -0000 Subject: [GHC] #7346: Allow the use of `deriving` for GHC generics In-Reply-To: <047.98a2cadfb420a57e4024d3aaa2403f08@haskell.org> References: <047.98a2cadfb420a57e4024d3aaa2403f08@haskell.org> Message-ID: <062.fe3d71df4fdf66bbcc88ab626020b5fd@haskell.org> #7346: Allow the use of `deriving` for GHC generics -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5462 -------------------------------------+------------------------------------ Changes (by dreixel): * status: new => closed * resolution: => duplicate * related: => #5462 Comment: Probably best to focus the discussion on #5462. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 11:47:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 11:47:01 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.4dd86e22b080973b169acd341683cc09@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7346 -------------------------------------+------------------------------------ Changes (by kosmikus): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 12:13:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 12:13:27 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.f3d65ad0d2e2019df0f9bc2983c3b02b@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Iceland_jack): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 12:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 12:13:37 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.6d86aea6a59fea315e051726ff757f8f@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Iceland_jack): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 12:16:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 12:16:28 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.c9310fa5b3c40407fad49cbed5612bd7@haskell.org> #5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------ Reporter: simonpj | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7346 -------------------------------------+------------------------------------ Changes (by basvandijk): * cc: v.dijk.bas@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 12:22:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 12:22:53 -0000 Subject: [GHC] #7028: incorrect link paths for in mac os x after install In-Reply-To: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> References: <050.5a49a7d43a2082b8077d439d3e55628b@haskell.org> Message-ID: <065.a89caa53f811446d727f0031e9dda20b@haskell.org> #7028: incorrect link paths for in mac os x after install ------------------------------------------+-------------------------------- Reporter: andykitchen | Owner: leroux Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC failed | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by darchon): I assume this is now fixed with #8266 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:22:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:22:39 -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.6e41a6f7d8549877f804738726c94060@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 performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by darchon): I believe let-floating happens due to the full-laziness transform. Do you get better performance with -fno-full-laziness ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:53:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:53:01 -0000 Subject: [GHC] #7954: Strictness analysis regression In-Reply-To: <052.14e09e0309816e5814d6943a3bf6024f@haskell.org> References: <052.14e09e0309816e5814d6943a3bf6024f@haskell.org> Message-ID: <067.7da632e1322bf4bbdddde2fc92c7ac62@haskell.org> #7954: Strictness analysis regression --------------------------------------------+------------------------------ Reporter: chad.scherrer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: perf/should_run/T7954 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"393ea739567206d848f53e9ca75f532a49218694/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393ea739567206d848f53e9ca75f532a49218694" Update test cases due to call arity Some nice improvements on already succeeding test cases (#876, #7954 and #4267) Test #149 needed a little change, lest call arity causes a allocation change that we do not want to test here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:53:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:53:02 -0000 Subject: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter In-Reply-To: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> References: <044.eddc5e125a508bcebb42e0b76be76c9d@haskell.org> Message-ID: <059.42b4e3db908848d0b76d787dc009538b@haskell.org> #4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"393ea739567206d848f53e9ca75f532a49218694/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393ea739567206d848f53e9ca75f532a49218694" Update test cases due to call arity Some nice improvements on already succeeding test cases (#876, #7954 and #4267) Test #149 needed a little change, lest call arity causes a allocation change that we do not want to test here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:53:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:53:02 -0000 Subject: [GHC] #876: Length is not a good consumer In-Reply-To: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> References: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> Message-ID: <069.b64c0d4f5efd8d7a2d77cba3a49c6812@haskell.org> #876: Length is not a good consumer --------------------------------------------+------------------------------ Reporter: ariep@? | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Operating System: Linux | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: perf/should_run/T876 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"393ea739567206d848f53e9ca75f532a49218694/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393ea739567206d848f53e9ca75f532a49218694" Update test cases due to call arity Some nice improvements on already succeeding test cases (#876, #7954 and #4267) Test #149 needed a little change, lest call arity causes a allocation change that we do not want to test here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:53:04 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.6083d6a66bb0a66190ad1bdf0783a290@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: T149 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"393ea739567206d848f53e9ca75f532a49218694/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="393ea739567206d848f53e9ca75f532a49218694" Update test cases due to call arity Some nice improvements on already succeeding test cases (#876, #7954 and #4267) Test #149 needed a little change, lest call arity causes a allocation change that we do not want to test here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:53:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:53:48 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode (was: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build: threaded RTS, profiling mode) In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.5f0a8461bb58fb0c76b8030b86ea67e5@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:54:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:54:10 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.15a53fec1c919927746f9547ce373bf3@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Unfortunately, the output object files did differ. I even did `objdump --source rts/dist/build/sm/Scav.o` and saw that the assembly output actually was different before and after the patch. I would guess that gcc isn't smart enough to in-line a usage like this: `my_var = inline_function(..., my_var, ...)`. It probably doesn't realize that there's no need to save `my_var` in a temporary. Should we abandon this ticket or is it worth merging anyway? I don't have any good judgement here since I'm not sure how hot this code is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:55:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:55:19 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.556384e4f25664572341d82cdcdaf8dd@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): With those 3 patches I've managed to get ghci running in --enable- unregisterised mode on amd64. Now ia64 build runs to see if it helps there (it should). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 13:57:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 13:57:31 -0000 Subject: [GHC] #7994: Make foldl into a good consumer In-Reply-To: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> References: <046.0488a8af5cd2e05ea028013de627d432@haskell.org> Message-ID: <061.b9bfb03b30676d506f3a7b508e6d45ba@haskell.org> #7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Heh, forgot to reference the ticket in the push. This has now been implemented in b63facef165b957183b65604ef99b2b8574747a5/base and requires the calla arity analysis (cdceadf365335fdee5ffa8e6364f7fb00bc4b0f7/ghc). This should not stop us from using superior approaches like Takano?s when they are ready. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 14:02:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 14:02:39 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.318b2cc43e78d7365d730db614c87c4f@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by AndreasVoellmy): The approach you mention is actually what the IO manager pre 7.8 did, although it didn't have `threadWait{Read,Write}WithTimeout` methods, so you would have to code this via the lower-level interface in `GHC.Event`. In the 7.8 IO manager, the approach you describe won't quite work. The 7.8 manager uses a separate `poll` instance to handle timeouts (much as you described) and uses `epoll` instances (one per HEC) to monitor files. The reason that we don't handle timeouts in the epoll instances anymore is that the 7.8 manager uses non-blocking calls to `epoll`, and it sometimes yields and moves to the back of the run queue of its HEC. This often reduces the number of blocking foreign calls. But it means that `epoll` may not be called in a timely fashion, because it may wait for a bunch of busy Haskell threads on its HEC to finish. For that reason, we keep a separate Haskell thread monitoring a `poll` instance just for timeouts. In contrast, in the pre-7.8 IO manager, the IO manager thread always did a blocking `epoll` call, so it could use the earliest timeout as the timeout for the `epoll` call. It would then have to wait for at most one Haskell thread to finish after the foreign `epoll` call returns in order to grab the HEC and dispatch callbacks. Tighter integration of the IO manager and the scheduler might help here. With the integration, we may not need the trick of sending the IO manager to the end of the run queue. Then we could probably match the latency characteristics of the pre-7.8 manager (wait at most one Haskell thread to fire callbacks) and the throughput of the 7.8 manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 14:20:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 14:20:14 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.3322b9f3c5e12e3c71dd61a5ea71ad81@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops --------------------------------------------+------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): > In contrast, in the pre-7.8 IO manager, the IO manager thread always did a blocking epoll call, so it could use the earliest timeout as the timeout for the epoll call. It would then have to wait for at most one Haskell thread to finish after the foreign epoll call returns in order to grab the HEC and dispatch callbacks. We don't guarantee to wake the thread up exactly after N milliseconds, so unless the new I/O manager seriously delays wake-ups, I'd prefer it if we could skip having a completely separate timeout manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 14:26:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 14:26:28 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.f414cb5d76069e6c02c02590f5074d63@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by darchon): It is probably related to the fact that ghci is now dynamically linked: 7.8-RC1: {{{ GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set +s Prelude> sum [1,2,3,4] 10 (0.03 secs, 0 bytes) }}} Statically linked HEAD (`DYNAMIC_BY_DEFAULT = NO; DYNAMIC_GHC_PROGRAMS=NO; GhcLibWays = v p`): {{{ GHCi, version 7.9.20140207: 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> :set +s Prelude> sum [1,2,3,4] 10 (0.05 secs, 8283104 bytes) }}} AFAIK, we can't have dynamic linking and profiling at the same time; so I don't know if this can be resolved before the release of 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 14:49:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 14:49:26 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.acb742b1e591b6d7bd8fad148e33d5ad@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Last patch adds missing declarations for hs_popcnt64. It fixes only a warning, but very scary one, as implicit declaration would mean {{{ int hs_popcnt64 (int); }}} Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 15:09:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 15:09:07 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.ff3a35777d30047227d8d000c785c228@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by hvr): I wonder what's different on OSX, as on Linux `:set +s` works even with dynamic (non-profiling) libs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 15:42:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 15:42:08 -0000 Subject: [GHC] #5982: Incorrect dynamic library name in OSX In-Reply-To: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> References: <043.e9dbce1f8a84aa40b605402efe6d469c@haskell.org> Message-ID: <058.2114f1f572c0614c658cfdd7baafaf40@haskell.org> #5982: Incorrect dynamic library name in OSX -----------------------------------+---------------------------------- Reporter: r0ml | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by darchon): Probably now fixed with #8266 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 15:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 15:43:54 -0000 Subject: [GHC] #5983: Libraries installed in wrong place In-Reply-To: <043.e001f11b98ff611be59707db8af989df@haskell.org> References: <043.e001f11b98ff611be59707db8af989df@haskell.org> Message-ID: <058.a51f0e011b50f2a0630956df86001fe0@haskell.org> #5983: Libraries installed in wrong place -----------------------------------+---------------------------------- Reporter: r0ml | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: libraries/base | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by darchon): Probably fixed by #8266 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:22:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:22:21 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.bd78005616d3d9bf4326247116605963@haskell.org> #7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): The simple example from the ticket: {{{ (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> [a] -> [b] foo f = map (id # f) }}} produces {{{ T7542.foo = \ (@ a) (@ b) (f :: a -> b) (eta :: [a]) -> GHC.Base.map @ a @ b (\ (eta1 :: a) -> f eta1) eta }}} without `-fpedantic-bottoms` and {{{ T7542.foo = GHC.Base.map }}} with, which looks fine. The same happens to the more elaborate example in comment:2 (middle section), `-fpedantic-bottoms` preserves the semantics and with that we get `map2 = map`. So it seems that situation has improved and we can close the ticket (which should not discourage anyone who finds a situation that needs fixing to open it again). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:25:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:25:32 -0000 Subject: [GHC] #5809: Arity analysis could be better In-Reply-To: <047.02f6239db7f1b75877296756661d2761@haskell.org> References: <047.02f6239db7f1b75877296756661d2761@haskell.org> Message-ID: <062.954a9c1e93edeb47af6daf653769f965@haskell.org> #5809: Arity analysis could be better --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Judging from the code, the new callartiy analysis should do exactly that (see that `block` is called with two arguments). Unfortunately, there is no small example here to verify this; but I?m optimistic. If you find that it does not work with today?s HEAD, I?d like to hear about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:33:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:33:35 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.7ab39736fcfd8294e8879f272153d63d@haskell.org> #3924: Strictness analyser missing useful strictness -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * difficulty: => Unknown Comment: This looks like it could be solved by the new callartiy analysis. It does not, though, because * all the functions are top-level functions, and callartiy analysis only looks at local functions, and * they are mutually recursive, which the callarity analysis does not handle yet. Both could possibly be fixed, but both carry an implementation and maintenance cost, I?d like to do that lazily, i.e. depending on real-world use cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:40:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:40:18 -0000 Subject: [GHC] #3698: Bad code generated for zip/filter/filter loop In-Reply-To: <041.1bc18587ecffea6f67a927d7ce3ba4be@haskell.org> References: <041.1bc18587ecffea6f67a927d7ce3ba4be@haskell.org> Message-ID: <056.3ff8cf0b3d50dc696ef182ba8ea80080@haskell.org> #3698: Bad code generated for zip/filter/filter loop --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: The new callarity analysis successfully eta-expands the monomorphic code. For the polymorphic code, there is nothing we can do, as guest mentions in comment:1. So I guess this can be closed. (I did not create a test case for this because these things are hard to test, and it is a standard application fo the callarity analysis, nothing tricky going on here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:45:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:45:25 -0000 Subject: [GHC] #3697: Method selectors aren't floated out of loops In-Reply-To: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@haskell.org> References: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@haskell.org> Message-ID: <056.b50966d5ad9f2788695bcfbed81e2dcc@haskell.org> #3697: Method selectors aren't floated out of loops --------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: With todays HEAD, I get good code: {{{ T3697.foo = \ (@ a) ($dEq :: GHC.Classes.Eq a) ($dNum :: GHC.Num.Num a) (as :: [a]) -> let { ds :: a [LclId, Str=DmdType] ds = GHC.Num.fromInteger @ a $dNum T3697.foo1 } in let { lvl :: a -> a -> GHC.Types.Bool [LclId, Str=DmdType] lvl = GHC.Classes./= @ a $dEq } in let { lvl1 :: a -> a -> a [LclId, Str=DmdType] lvl1 = GHC.Num.- @ a $dNum } in letrec { go [Occ=LoopBreaker] :: [a] -> [a] [LclId, Arity=1, Str=DmdType ] go = \ (ds1 :: [a]) -> case ds1 of _ [Occ=Dead] { [] -> GHC.Types.[] @ a; : y ys -> let { x :: a [LclId, Str=DmdType] x = lvl1 y y } in case lvl x ds of _ [Occ=Dead] { GHC.Types.False -> go ys; GHC.Types.True -> GHC.Types.: @ a x (go ys) } }; } in go as }}} Given the age of the bug, I don?t dare to guess what has fixed this. Also, hard to make a useful testcase here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:48:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:48:53 -0000 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> References: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> Message-ID: <061.2a45e0072fe80236c7075412b0118f24@haskell.org> #2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => infoneeded Comment: I don?t understand this ticket: Why should `f` have arity 1? It would be eta-expanded, and we?d be losing work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 16:52:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 16:52:21 -0000 Subject: [GHC] #2823: Another arity expansion bug In-Reply-To: <046.50a7eb0bd1d6f872efa506bccfff4122@haskell.org> References: <046.50a7eb0bd1d6f872efa506bccfff4122@haskell.org> Message-ID: <061.28b50212fd7fe4fd1483e5612f65e3c9@haskell.org> #2823: Another arity expansion bug --------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: It seems that this has been fixed in ghc-7.6.3 or before: {{{ T2823.foo [InlPrag=NOINLINE] :: forall a. GHC.Classes.Eq a => a -> a [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType AS] T2823.foo = \ (@ a) _ (x :: a) -> x T2823.bar [InlPrag=INLINE[1] (sat-args=1)] :: forall a. GHC.Classes.Eq a => a -> a [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL] T2823.bar = \ (@ a) ($dEq :: GHC.Classes.Eq a) (eta :: a) -> let { p [Dmd=Just L] :: (a, a) [LclId, Str=DmdType] p = T2823.foo @ (a, a) (GHC.Classes.$fEq(,) @ a @ a $dEq $dEq) (eta, eta) } in let { $dEq1 [Dmd=Just A] :: GHC.Classes.Eq (a, a) [LclId, Str=DmdType] $dEq1 = GHC.Classes.$fEq(,) @ a @ a $dEq $dEq } in case T2823.foo @ ((a, a), (a, a)) (GHC.Classes.$fEq(,) @ (a, a) @ (a, a) $dEq1 $dEq1) (p, p) of _ { (x, _) -> case x of _ { (x1, ds2) -> x1 } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 17:01:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 17:01:54 -0000 Subject: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell In-Reply-To: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> References: <047.4ab77c9ab178c03fa49c4bf5e6df9f96@haskell.org> Message-ID: <062.ce9c5692686e2e6afbe305cf0af85833@haskell.org> #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: closed Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: fixed | Related Tickets: Operating System: | Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | th/T7021 | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): Here is the relevant commit to TH: http://git.haskell.org/packages/template- haskell.git/commitdiff/57b662c3efd8579595c8642fce2d4cd60ba4ec0b In short, we've equated predicates with types (`type Pred = Type`) and added a new constructor to `Type`, `EqualityT :: Type`, which represents `(~)`. Thus, this would break any code that uses predicates in Template Haskell. That's a fair amount of breakage, but, as I said, I think this change is forward-thinking, especially given that predicates and types are the same type within GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 17:05:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 17:05:21 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.aafa6826ba14540ef690546ffdb80d52@haskell.org> #7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ekmett): @nomeata: As I understand the situation, the fact that this optimization isn't happening without `-fpedantic-bottoms` means I'm basically stuck using the existing hacks in `lens`. The code in question is set up to `INLINE` in library into user code, and they very likely aren't compiling with that flag! (Unless I'm misunderstanding how and where that gets tracked and applid.) We have 3 cases to consider, the existing unsafeCoerce hack, the naive eta expansion we're getting without `-fpedantic-bottoms`, and the version without the eta expansion we can produce with `-fpedantic-bottoms`. It appears that the first and the third scenarios are now the same, but the difference in performance between the existing unsafeCoerce hack and the eta expanded code can be asymptotic, if this is closed as is, the fix does me no good, and I'll be left using the existing coercions to ensure a good user experience. =/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 17:22:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 17:22:43 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.025577ec801f2bded5005f2cdd080a14@haskell.org> #7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): @ekmett: Ok, thanks for the input. So clearly it should _not_ be closed then. So what you?d like to see is to have GHC behave here as if `-fpedantic- bottoms` is on always. Obviously, one could make that flag the default, but there must be reasons why it is not the default. What I find surprising: The core generated for {{{ mkIdDot2 :: (a -> b) -> a -> Id b mkIdDot2 f = f `seq` \x -> MkId (f x) }}} is {{{ mkIdDot2 = (? f. f) |> (some cast involving Id)) }}} which is the same core that we get with `mkIdDot2 = coerce` (hey, no unsafe!), but the latter produces the desired `map2 = map`... hard to see (without knowing the simplifier by heart) where this goes wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 17:35:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 17:35:48 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.b46a8da9e97175fd9b4441f66ec75c34@haskell.org> #7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Ah, interesting. The problem is not `mkIdDot2` (that has Arity 1 allright), the problem is `unIdDot2`, which suddenly as artiy 2! {{{ T7542.unIdDot2 :: forall a_az8 b_az9. (a_az8 -> T7542.Id b_az9) -> a_az8 -> b_az9 [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 50 0}] T7542.unIdDot2 = \ (@ a_aKU) (@ b_aKV) (f_aze :: a_aKU -> T7542.Id b_aKV) (eta_B1 :: a_aKU) -> case f_aze of f_Xzl { __DEFAULT -> T7542.unId @ b_aKV (f_Xzl eta_B1) } }}} (This is already after `InitialPhase [Gentle]`). One would expect `MkId` and `unId` to behave the same... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 17:47:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 17:47:50 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.3a3bfcee4d120419f9966cf54e913716@haskell.org> #7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Tracing this back I found the `Note [Dealing with bottom]` in `CoreArity`, where the arity of case branches is used to calculate the arity of a case. Quote: > We ignore this "problem" (unless -fpedantic-bottoms is on), because being scrupulous would lose an important transformation for many programs. (See Trac #5587 for an example.) So the next step would be answering: Can we distinguish between cases where this dodgy optimization is useful and required, and cases where it hurts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 10 18:38:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Feb 2014 18:38:22 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.9d695f27e93334db95a311281c9bf35e@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+---------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 8748 ----------------------------------------+---------------------------------- Changes (by trommler): * architecture: powerpc64 => Unknown/Multiple * related: => 8748 Comment: Ticket #8748 contains a series of patches to fix unregisterized builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 02:26:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 02:26:35 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster Message-ID: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster ------------------------------+-------------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Compared to 7.6.3 length in 7.8.1-rc1 has a performance regression: {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.20140130 bash-3.2$ ghc -O2 LengthIntegerList.hs [1 of 1] Compiling Main ( LengthIntegerList.hs, LengthIntegerList.o ) Linking LengthIntegerList ... bash-3.2$ time ./LengthIntegerList 1073741824 real 0m45.344s user 0m44.230s sys 0m0.494s bash-3.2$ /usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 bash-3.2$ /usr/bin/ghc -O2 LengthIntegerList.hs [1 of 1] Compiling Main ( LengthIntegerList.hs, LengthIntegerList.o ) Linking LengthIntegerList ... bash-3.2$ time ./LengthIntegerList 1073741824 real 0m22.769s user 0m22.042s sys 0m0.385s bash-3.2$ cat LengthIntegerList.hs {-# OPTIONS_GHC -Wall #-} module Main where main :: IO() main = print $ length [1..(2^(30::Int)::Integer)] }}} thus length of [Integer] is twice as slow in rc1 but length of [Int] is 10 times faster: {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.20140130 bash-3.2$ ghc -O2 LengthIntList.hs [1 of 1] Compiling Main ( LengthIntList.hs, LengthIntList.o ) Linking LengthIntList ... bash-3.2$ time ./LengthIntList 1073741824 real 0m0.723s user 0m0.693s sys 0m0.003s bash-3.2$ /usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 bash-3.2$ /usr/bin/ghc -O2 LengthIntList.hs [1 of 1] Compiling Main ( LengthIntList.hs, LengthIntList.o ) Linking LengthIntList ... bash-3.2$ time ./LengthIntList 1073741824 real 0m11.805s user 0m10.900s sys 0m0.351s bash-3.2$ cat LengthIntList.hs {-# OPTIONS_GHC -Wall #-} module Main where main :: IO() main = print $ length [1..(2^(30::Int)::Int)] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 04:56:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 04:56:54 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.dc218f6fe47269692c4c2070095c0197@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Difficult (2-5 warning at compile-time | days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 08:59:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 08:59:44 -0000 Subject: [GHC] #8420: Spurious dynamic library dependencies In-Reply-To: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> References: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> Message-ID: <068.3e2857f33802249816023bee7fb3b90a@haskell.org> #8420: Spurious dynamic library dependencies -----------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by darchon): It doesn't just apply to OS X, also to linux: {{{ [10:19am] Does https://ghc.haskell.org/trac/ghc/ticket/8420 also apply to linux? [10:30am] yeah, it does. -Wl,--as-needed partially mitigates it, but RPATH is left }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 09:15:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 09:15:42 -0000 Subject: [GHC] #8420: Spurious dynamic library dependencies In-Reply-To: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> References: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> Message-ID: <068.66e34655dd34f0659d0f0626d1ee2889@haskell.org> #8420: Spurious dynamic library dependencies -----------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by nomeata): I also noticed the problem; we?d like to generate our Debian package dependencies based on what files are linked, but currently that is an over-approximation. I.e. lots of stuff links to libgmp. I believe Ubuntu and OpenSUSE patch their build to use `-Wl,--as-needed`, but I refrained from it, to prevent unnecessary divergence. But I would very much welcome if GHC would build with `-as-needed`, preferably already in GHc-7.8 (as now we build `libHS*.so` files by default for all packages). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 09:39:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 09:39:03 -0000 Subject: [GHC] #8420: Spurious dynamic library dependencies In-Reply-To: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> References: <053.6d20c8a5a1dda98693fe4739c5ec23a3@haskell.org> Message-ID: <068.650b68f73e506886a21f3692e8172a2c@haskell.org> #8420: Spurious dynamic library dependencies -----------------------------------+------------------------------------ Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by darchon): It would be my guess this has something to do that the original pipeline was build with static linking in mind. In which case you would need the transitive closure of the libraries you depend on? Looking at `linkBinary'` in `compiler/main/DriverPipeline.hs`, I see that it just gets a list of `PackageId`'s that must be linked, for which, as far as I can see, there is no differentiation between dynamic linking and static linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 10:47:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 10:47:35 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.98e33013a11129709f8734bffebd6fc8@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): ...here's what simplified Core of {{{#!hs intlen :: Int intlen = length [1..(2^(30::Int))::Int] }}} looks like for GHC 7.6.3: {{{ intlen = case $wf 2 30 of ww { __DEFAULT -> case $wlen (eftInt 1 ww) 0 of ww1 { __DEFAULT -> I# ww1 } } }}} vs. GHC 7.8.20140130: {{{ intlen = case $wf 2 30 of ww4 { __DEFAULT -> case tagToEnum# (># 1 ww4) of _ { False -> letrec { $wgo $wgo = \ w w1 -> case tagToEnum# (==# w ww4) of _ { False -> $wgo (+# w 1) (+# w1 1); True -> +# w1 1 }; } in case $wgo 1 0 of ww { __DEFAULT -> I# ww }; True -> I# 0 } } }}} So the significant runtime reduction for the `Int`-case is seemingly due to proper inlining of `eftInt` and thus turning a `length [a..b]` into a tighter counting-loop w/o any `[Int]` involved anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 10:58:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 10:58:55 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.58c02e6c24c9538e5475f67a7892dd43@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): The improvement for `Int` is most likely from 82f56e5 (#876). But I guess the important point of the ticket is the regression for `Integer`. Maybe it is because of #8638? There might now be many checks whether the value fits in a `S#` that were not done before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 11:01:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 11:01:15 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.9510891ada0bd2a7a086796c030b6a00@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Nevermind, 82f56e5/integer-gmp did not change addition, so it should not be the problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 11:14:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 11:14:55 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.f02dc4d8f33aaa33fa0ddc6a8c61f4fc@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:2 nomeata]: > The improvement for `Int` is most likely from 82f56e5 (#876). But I guess the important point of the ticket is the regression for `Integer`. I was getting to that (needed to verify something first though): The Core for {{{#!hs intlen = length [1..(2^(30::Int))::Integer] }}} Otoh, looks differs as following: GHC 7.6.3: {{{ intlen1 = enumDeltaToInteger intlen3 intlen3 intlen2 }}} vs. GHC 7.8.20140130: {{{ intlen1 = enumDeltaToIntegerFB (incLen) I# intlen3 intlen3 intlen2 }}} The use of `enumDeltaToIntegerFB` instead of `enumDeltaToInteger` accounts for the speed difference. I've verified that by copying the definition from `GHC.Enum` into the test-code and using `enumDeltaToInteger` directly with GHC 7.8.20140130 which resulted in a slightly better runtime than for GHC 7.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 11:25:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 11:25:19 -0000 Subject: [GHC] #8753: Import constructor but not the data type In-Reply-To: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> References: <051.5bc5ea156b4767e3f02eeeb6e1c516d6@haskell.org> Message-ID: <066.8e5cd06c4d4061175718637ac2e4d26c@haskell.org> #8753: Import constructor but not the data type -------------------------------------+------------------------------------ Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by andreas.abel): Indeed, they could do the job, but are they in ghc 7.6? I have not tried ghc 7.7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 12:32:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 12:32:59 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.e62260f3ee8aec1476e389b91c285622@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * version: 7.6.3 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 12:33:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 12:33:30 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.a1eff2a10a524de6648476f1523fbce8@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 12:36:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 12:36:11 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.ad7a1f56bce3a29defc5301a97f015c4@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by slyfox): I've noticed it today as well. What was strange is that absence of ghc-split does not fail the build even when -split-objs is specified in ghc commandline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 12:41:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 12:41:54 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.94cde4197ad193d875b7c820e2f312e5@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by MagnusTherning): Replying to [comment:2 slyfox]: > I've noticed it today as well. > > What was strange is that absence of ghc-split does not fail the build > even when -split-objs is specified in ghc commandline. It looks like the script is properly installed for use in-place during the build of Ghc (at least an executable copy is present after a build). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 12:54:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 12:54:24 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.938fb38829cc507ea8791bf4fb26e7cd@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 13:33:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 13:33:19 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.96b6238f9e764daf558a459a0ca999a6@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Changes (by trommler): * related: => 8301 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 13:33:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 13:33:52 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.b7d3e8ae956c59643a87861cbfba84bb@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Changes (by trommler): * cc: ptrommler@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 13:45:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 13:45:56 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.76a3f29113cbf30d133b17c3fe76abcc@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I changed the definition of `coerce` back to the naive one, and aimed at making the rule matcher smarter. I did this by adding a function `exprIsLambda_maybe` which is used when a rule template contains a lambda. Previously, the code would either use a Lambda, if its there, or eta- expand both sides otherwise. The latter seemed to be somewhat dangerous (could waste work, although I could not produce a example for that due to later CSE and other effects), and did not help in the case discussed here. So instead I try to ?make the expression? into a lambda. Either it already is a lambda, or it is a (nested) application of something that has a currently active unfolding which is unsaturated: In that case, unfold it, `simpleOptExpr` and recursively look for further lambdas. Any any cast occurring while doing so will be pushed inside the lambda. With that change, matching `unsafeCoerce` works as well! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 15:40:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 15:40:15 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.08eb495138c5833da65a9598ebdc10b9@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"b4715d67ae90f4cc847daa94f0fc056a40057d65/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4715d67ae90f4cc847daa94f0fc056a40057d65" Replace forall'ed Coercible by ~R# in RULES we want a rule "map coerce = coerce" to match the core generated for "map Age" (this is #2110). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 15:40:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 15:40:16 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.b7cad90482d0f4853efa9c0ca3b2bd4b@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"377672ae068f6dbfa0354dfab95f41bdd26b0df4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="377672ae068f6dbfa0354dfab95f41bdd26b0df4" Test case for RULE map coerce = coerce (This tests #2110.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 15:44:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 15:44:41 -0000 Subject: [GHC] #8767: Add rules involving `coerce` to the libraries Message-ID: <046.3c0b9cf8af710082a3b44b8616f52521@haskell.org> #8767: Add rules involving `coerce` to the libraries ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 8718 | Blocking: Related Tickets: #2110 | ------------------------------------+------------------------------------- With #2110 fixed, we can now add rules like {{{ {-# RULES "map/coerce" [0] map coerce = coerce #-} }}} to the standard libraries. But probably this should happen together or after #8718. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 15:45:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 15:45:09 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.fa18d27f202dfff249422524c468584a@haskell.org> #2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8767 -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed * related: => #8767 Comment: Ok, pushed in patches {{{ git log b4715d67^...cde88e20 }}} Patch f4fb94f3 has a small improvement of compiler performance as a side- effect (which I did not investigate further). The ask of actually adding such rules is tracked in #8767. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 17:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 17:46:33 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) Message-ID: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ----------------------------------+--------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm configuring and building {{{haskell-src-exts}}} like this: {{{ runhaskell Setup configure -O -p --enable-shared \ -fbase4 runhaskell Setup build }}} It builds the ordinary bits just fine, but when it gets to compiling for profiling: {{{ [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc340_0/ghc340_8.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 19:28:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 19:28:53 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.47e13b0e65767bdd412ac5dfb4016e59@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Safe Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * cc: nomeata (added) Comment: The GND change seems reasonable to me, and I believe we discussed it prior to this (but I can't find the mailing list post just yet) - we just need to remove `-XGeneralizedNewtypeDeriving` from `unsafeFlags` in `DynFlags`. I'm not so sure about Coerce though, at least not yet - we're still considering it somewhat experimental I think, so perhaps exposing it to Safe Haskell isn't the best idea just yet. Joachim, what are your thoughts on this? Do you think we should consider `Coercible` as safe? If so, I'm willing to defer to you here (and I'll even write the patch - but not sure where to export it from - perhaps a `Trustworthy` module called `GHC.Coerce`?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 19:34:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 19:34:51 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.0e4526318b2ab68f2832a747c6a97a81@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): What GCC and binutils (or associated compiler/assembler tools) are you using ''exactly''? The thing is, this is actually a bug in GNU as or GCC it seems, as the choke happens when compiling the resulting profiled assembly code created by GHC - GHC has already done its job. There may be a possible way to work around this, but I'll need to know exactly what system you're on first to be sure I can reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 20:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 20:29:12 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.3668126b03fd96a8bdeefe7fc60e1577@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Safe Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): The comments I've seen in relation to this are all in #5498. GND is now actually built on top of `coerce`, so I think it's a little incongruent to have one be Safe but not the other. To be fair, I'm not 100% sure that GND should be Safe, myself. While I am as confident as I can be about its type safety, it is very easy to imagine a library author omitting a key role annotation that would allow clients to (perhaps unwittingly) break class coherence or invariants. For example, if `base`'s `Set` doesn't have a role annotation, it would be very easy to cause the `Set` operations to misbehave. Simon PJ has advocated (see #5498) that GND should be Safe, on the other hand. My goal in creating this ticket is to make a reasoned decision on the matter, as opposed to letting inertia make the decision for us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 20:39:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 20:39:18 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs Message-ID: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> #8769: Minor refactoring of Maybe.lhs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Minor refactoring in Maybe.lhs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 20:41:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 20:41:04 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.dab81b8e8535e74bf749a95569a2b3ac@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by Iceland_jack): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 21:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 21:17:23 -0000 Subject: [GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) In-Reply-To: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> References: <053.ae7a9c3fdcc3ad097c545276432149e8@haskell.org> Message-ID: <068.d8f29cbba7cc5126736e2f09be18bf5d@haskell.org> #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ---------------------------------------+---------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by MagnusTherning): Replying to [comment:1 thoughtpolice]: > What GCC and binutils (or associated compiler/assembler tools) are you using ''exactly''? > > The thing is, this is actually a bug in GNU as or GCC it seems, as the choke happens when compiling the resulting profiled assembly code created by GHC - GHC has already done its job. There may be a possible way to work around this, but I'll need to know exactly what system you're on first to be sure I can reproduce it. It's an up-to-date ArchLinux system: {{{ # pacman -Q binutils gcc binutils 2.24-2 gcc 4.8.2-8 }}} Let me know if there is more information you need from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 22:39:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 22:39:04 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.4a797719020fef98a8a1cd9d32190990@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Safe Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): We have some special handling in Safe mode in place where we do the Coerible thing, but it is neither well tested nor well discussed. (`getCoercibleInst` in `TcInteract`) Currently, in Safe Mode, the following additional restrictions exist when checking whether something is `Coercible`: > To coerce under a type constructor, ''all'' data constructors of ''all'' type constructors involved in the definition of that type constructors need to be in scope. No additional constraint is put on unfolding a newtype, but there we already require the constructor to be in scope. I believe that this condition is sufficient for ?the use can implement coerce himself (ignoring the run-time cost)?. If anything, it might turn out too strong. If that works as intended, `Coercible` and GND should be safe. There might possibly be ways to break it, maybe with different modules, some safe and some not... but that would simply be bugs then, and I?m not claiming bug freeness. A trustworthy `GHC.Coerce` might be nice. Or maybe even `Data.Coerce`? After all the interface could be provided by other compilers as well... Not only for Safe, but to avoid people having to import the mingle-mangle of `GHC.Exts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 11 22:46:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Feb 2014 22:46:55 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.28643f9540d08e1a6c042bcac4c78564@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): Is there a reason why you did not remove `mapCatMaybes` completely, and replaced it by `Data.Maybe.mapMaybe`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 00:51:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 00:51:14 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.1d4535711bed26fc3951c79db9f521c8@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Iceland_jack): No reason really, wouldn't it be a matter of replacing every occurrence of `mapCatMaybes` with `mapMaybe` since `Maybes` already exports `Data.Maybe`? Should I add a patch for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 01:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 01:18:58 -0000 Subject: [GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing In-Reply-To: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> References: <045.4c9eb90270eb503495dbeb412abc60e7@haskell.org> Message-ID: <060.5a14504c602d4720803a12f5e5cc49e5@haskell.org> #8429: GHC.Base.{breakpoint, breakpointCond} do nothing -------------------------------------+------------------------------------ Reporter: refold | Owner: iand675 Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 1377 -------------------------------------+------------------------------------ Changes (by jkarni): * cc: jkarni@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 02:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 02:03:05 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.034410baf2c55ec1e997be5d9de7c7b0@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Safe Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I had forgotten about this detail. With this in place (is it tested by anything in the testsuite?), I'm much more in favor of labeling GND and `coerce` as Safe. It's possible that the (rather draconian, admittedly) check that Joachim (nomeata) describes could be relaxed in the future once library authors are more familiar with role annotations. I no longer see a downside to making GND and `coerce` Safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 02:36:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 02:36:42 -0000 Subject: [GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) Message-ID: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) -----------------------------------+--------------------------------- Reporter: z9p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: dlopen dylib so | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- I am using ghc-7.6.3 on MacOSX 10.9.1. I noticed that when -l foo option is specified to ghci, it assumes the shared library extension is .dylib and tries to load foo.dylib. Even though a valid foo.so is present while foo.dylib is not, ghci ignores the .so and signals an error. This is in contradiction to the behavior of gcc and python on MacOSX. gcc would check the existence of both .so and .dylib and try to link them. Python is able to load the .so as well. Notice that here the .so is simply a renamed Mach-O .dylib. The reason I raise this issue is, in my case, I use macports to install cern ROOT and its shared libraries are all installed as .so files under /opt/local/lib. I would like to use them without change or creating .dylib -> .so links. $ ghci -lGui GHCi, version 7.6.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. Loading object (dynamic) Gui ... failed. : user specified .o/.so/.DLL could not be loaded (dlopen(libGui.dylib, 9): image not found) Whilst trying to load: (dynamic) Gui Additional directories searched: (none) $ ln -s libGui.so libGui.dylib $ ghci -lGui GHCi, version 7.6.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. Loading object (dynamic) Gui ... done final link ... done Prelude> -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 03:05:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 03:05:26 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.662f06ac4119d479a9ce982660cb7b95@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Safe Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I've found a weird corner case that is very relevant. Consider {{{ class Foo a where ... type role Foo representational data PackFoo a where MkPF :: Foo a => PackFoo a instance Foo Int where ... newtype Age = MkAge Int instance Foo Age where ... incoherent :: PackFoo Age incoherent = coerce (MkPF :: PackFoo Int) useIncoherent = case incoherent of MkPF -> {- here, we two incompatible instances of Foo Age available! -} }}} The problem, as I see it, boils down to the role annotation on `Foo`, which allows users to create incoherence. Should we perhaps disallow role annotations on classes in Safe Haskell? It would be analogous to the restrictions on overlapping instances, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 06:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 06:29:12 -0000 Subject: [GHC] #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs Message-ID: <045.20216dcc8b13adab2aebca9b575a94de@haskell.org> #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs -------------------------------------+------------------------------------- Reporter: jkarni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- An ASSERT macro in compiler/coreSyn/CoreSubst.lhs isn't being expanded because of a space before the parens. The error: {{{ make -j3 ... "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-db libraries/bootstrapping.conf -package-name ghc-7.9 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.4.0.1 -package base-4.6.0.1 -package bin-package- db-0.0.0.0 -package bytestring-0.10.0.2 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.1.0.2 -package time-1.4.0.1 -package transformers-0.3.0.0 -package unix-2.6.0.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DSTAGE=1 -fwarn-tabs -O -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/coreSyn/CoreSubst.lhs -o compiler/stage1/build/CoreSubst.o compiler/coreSyn/CoreSubst.lhs:1360:7: Not in scope: data constructor `ASSERT' make[1]: *** [compiler/stage1/build/CoreSubst.o] Error 1 make: *** [all] Error 2 }}} /usr/local/bin/ghc is version 7.6.3. I'm building HEAD, which is at commit 5d04603b33d285565774, though a27b2985511800fa3b740fef82 (HEAD~2) introduced the code in question. This is, I'm pretty sure, literally a one character (and a whitespace, at that) fix. Attached is the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 08:57:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 08:57:18 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.4e1aadf8ad4ae9618877e181afa78703@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): Yes; while you are at it just do a thorough cleanup. Just make sure you don?t use any recent additions to base (if there are any); Anything in http://hackage.haskell.org/package/base-4.3.0.0 is ok I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 09:01:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 09:01:17 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.ccdc1b3fac6545ab383c133c60bdef96@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by nomeata): * testcase: => should_fail/TcCoercibleFailSafe Comment: > With this in place (is it tested by anything in the testsuite?) One simple test case is in place (`typecheck/should_fail/TcCoercibleFailSafe`). > class Foo a where ... > type role Foo representational Why is that even accepted? I thought role annotation can only stricten roles (i.e. P?N, P?R, R?N), and we have decided that classes have role nominal by default, so I would expect `type role Foo representational` to be rejected even in non-Safe Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 09:22:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 09:22:02 -0000 Subject: [GHC] #8772: ghci should safe history more often Message-ID: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> #8772: ghci should safe history more often ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It is very annoying if `ghci` crashes (due to using a foreign library wrongly, for example), and then the history is lost. It should be simple to save each line to history before it is being executed. Maybe a good task for new contributors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 10:27:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 10:27:13 -0000 Subject: [GHC] #8772: ghci should save history more often (was: ghci should safe history more often) In-Reply-To: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> References: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> Message-ID: <061.d63691987e2686e3b10e139cfe0eaf21@haskell.org> #8772: ghci should save history more often ----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 10:39:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 10:39:31 -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.4546d52ab5fa21908aec5027722984ac@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 performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): A comment in `SetLevels` (which I just came across) in the code indicates that this problem should have been taken care of: {{{ -- We are keen to float something to the top level, even if it does not -- escape a lambda, because then it needs no allocation. But it's controlled -- by a flag, because doing this too early loses opportunities for RULES -- which (needless to say) are important in some nofib programs -- (gcd is an example). }}} So either my assumption is wrong, or this does not work as desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 10:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 10:50:30 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.119fe1cad2e254e9c97e0fea419390b6@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Is the code better or worse with the inline function? I'd be surprised if gcc wasn't smart enough to optimise that. But that's why we test these things rather than assuming it'll work. The GC has various workarounds for quirks and missing optimisations in gcc; I tend to treat the whole of the GC as performance-critical code. If you want to share this code without the performance loss (and the inline function really doesn't work) then maybe try a macro, if that's not too ugly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 10:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 10:52:38 -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.827322bf5ab08089e6365dd44b1c0dc3@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 performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): It turns out that this comment is obsolete; the flag is never set. I quote from `SimplCore` {{{ -- Was: gentleFloatOutSwitches -- -- I have no idea why, but not floating constants to -- top level is very bad in some cases. -- -- Notably: p_ident in spectral/rewrite -- Changing from "gentle" to "constantsOnly" -- improved rewrite's allocation by 19%, and -- made 0.0% difference to any other nofib -- benchmark }}} This comment was introduced in eaeca51efc0be3ff865c4530137bfbe9f8553549 (2009) by SPJ. Maybe rules matching should look though unfoldings more easily (at the risk of losing sharing)? There is no point in worrying about sharing `[0..N]` in a rule application whose purpose is to eliminate that list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 11:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 11:56:56 -0000 Subject: [GHC] #8772: ghci should save history more often In-Reply-To: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> References: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> Message-ID: <061.ccf15c8f6716356c2e9220e1daa4c315@haskell.org> #8772: ghci should save history more often -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.6.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by nomeata): * component: GHCi => libraries (other) Comment: Looking at the code, it seems that this needs to be implemented in haskeline -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 13:09:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 13:09:08 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.9e386ed468014f3240f45c554e714341@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): With aggressive floating out bounded by multi-way-cases, the changes are less dramatic: {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- knights +0.5% -23.1% 0.01 0.01 0.0% mandel2 +0.4% +46.6% 0.00 0.00 0.0% -------------------------------------------------------------------------------- Min +0.3% -23.1% -20.2% -19.7% -20.0% Max +1.3% +46.6% +1.9% +1.9% +3.6% Geometric Mean +0.5% -0.0% -4.1% -4.2% -0.3% }}} Will investigate what happened with mandel2 now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 14:51:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 14:51:46 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.8341481de1a02b46a08d8e46fb3bbf3f@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Hmm, tricky. The Increase in allocation happens in `check_perim` (which produces quite ugly code; if this were real code I?d suggest the author to put in some strictness annotation on the floats...). There are multiple calls to `point_color`, which call `np` resp. `nq` on the coordinates of its arguments. These calculations are shared. How does that increase allocations? Hard to tell, even with ticky-ticky-profiling. But it seems that there is still stuff floating past multi-way cases, and it is hard to avoid. If there is a nested expression `(C1 (C2 x))`, and `(C1 (C2 x))` is worth floating on its own, it is floated past multi-way- cases, preserving existing behavior. But if `C2 x` is also optimistically floated out, it is now outside the multi-way case and might be CSEd there with values from other branches, even if `C1 lvl` itself gets floated back in. But then, I?m not entirely sure that this is main reason for allocation increase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:11:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:11:55 -0000 Subject: [GHC] #5682: Properly parse kind operators (from promoted type operators) In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.b0ed8c1b9fdfadf35b7f2c9b12c16379@haskell.org> #5682: Properly parse kind operators (from promoted type operators) -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 Blocking: | -------------------------------------+------------------------------------- Changes (by dreixel): * owner: dreixel => * priority: low => normal * component: Compiler => Compiler (Parser) * related: => #8486 Comment: I don't think this is low priority; #8486 (inability to derive `Typeable` for promoted `:`), in particular, is rather annoying. But I'm removing myself as the owner, as I don't really feel comfortable hacking around in the parser... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:18:33 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.0a5b089e34d5d4caab7a44ca03cf792f@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): The role annotation story is this: the annotations, if provided, simply override defaults (phantom for datatypes, nominal for classes). Then role inference happens (annotations or no). If, after inference, the annotations disagree with the inferred roles, the annotation is rejected. Because it's perfectly type-safe to have a class with a representational parameter, the role annotation is accepted and works. This can be useful if, say, someone wanted to have something like `Coercible` implemented in user-land somehow -- note that `Coercible`'s parameters are representational. One way forward here is to allow role annotations on classes only when we have !IncoherentInstances. In fact, I rather like that solution -- a role annotation on a class quickly leads to the possibility of incoherence, and this solution also neatly prohibits such annotations in Safe Haskell. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:31:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:31:48 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.ed1abd4aa6bb4e24e08916c4176f4dca@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): > One way forward here is to allow role annotations on classes only when we have IncoherentInstances. In fact, I rather like that solution -- a role annotation on a class quickly leads to the possibility of incoherence, and this solution also neatly prohibits such annotations in Safe Haskell. Thoughts? That?s what I was about to propose as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:35:12 -0000 Subject: [GHC] #5682: Properly parse kind operators (from promoted type operators) In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.ffaebffa943968005b2eb4eccef80d99@haskell.org> #5682: Properly parse kind operators (from promoted type operators) -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 Blocking: | -------------------------------------+------------------------------------- Comment (by goldfire): There seems to be two different (but closely related) issues here: (1) parsing promoted data constructor operators, and (2) parsing promoted type constructor operators. The motivating example at the top of the report is only about issue (1). And, I believe that Pedro (dreixel)'s recent comment is also only about (1). Pedro's first comment to this ticket, however, is about issue (2). I think issue (2) is unsolvable, due to the presence of `*` in the grammar of kinds. See #8706. But, I do think (1) should be doable. Do I feel ''comfortable'' in the parser? By no means. But I've done a little poking about in there and might be able to fix this. Hopefully tomorrow. If someone out there does feel comfortable in the parser, I'm happy to let you do it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:39:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:39:50 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions Message-ID: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8745 | ------------------------------------+------------------------------------- With a role annotation declaring a representational role for a class parameter, it is very easy to create instance incoherence. See [https://ghc.haskell.org/trac/ghc/ticket/8745#comment:5 this comment]. The solution: require `-XIncoherentInstances` when writing such a role annotation. This also has the knock-on effect (happily) of preventing such shenanigans in Safe Haskell. Class role annotations asking GHC to infer roles or with nominal roles, although rather useless, will still be accepted without `-XIncoherentInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:40:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:40:44 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.e800a02f3ad2ccdf77ffe6d6f842ecea@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): Great. I've made #8773 to track that offshoot of this bug. I expect to do it and push tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:58:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:58:38 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.2ee5bc6faee5640ab31affaaef2efb7a@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8745 -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 15:59:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 15:59:41 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators (was: Properly parse kind operators (from promoted type operators)) In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.d3540e0b9a5f60b4322611a9bae7b6d0@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 Blocking: | -------------------------------------+------------------------------------- Comment (by dreixel): Richard, I agree that parsing promoted type operators (thus when parsing kinds) is trickier. Let's make this ticket be only about parsing promoted constructor operators (thus when parsing types), and leave #8706 for kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 16:02:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 16:02:06 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.2760aa358838a3d66ab80b3b69553de4@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dreixel): Is `*` the only problem here? If so, can't we promote everything else, and just refuse to promote type constructor operators named `*`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 16:26:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 16:26:18 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.cf159eef5580eb0919dc79001c44371c@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by slyfox): * cc: slyfox@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 16:32:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 16:32:28 -0000 Subject: [GHC] #8024: Dynamic linking not working on PowerPC Linux. In-Reply-To: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> References: <044.9ac099edab3e89a81000a0e47392a6e5@haskell.org> Message-ID: <059.9325ac78ec263f7405cf9b5a9418b5d1@haskell.org> #8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by slyfox): I see odd things happening on sparc and ia64 as well. On sparc it looks like a wrongly resolved current module (seems to be PIC mis-handling). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 17:32:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 17:32:54 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization Message-ID: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------+------------------------------------------------- Reporter: | Owner: crockeea | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Linux Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: 5928, | 8668, 8099 | -------------------------+------------------------------------------------- From [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/pragmas.html#idp49866112 the docs]: [Y]ou often don't even need the SPECIALIZE pragma in the first place. When compiling a module M, GHC's optimiser (with -O) automatically considers each top-level overloaded function declared in M, and specialises it for the different types at which it is called in M. The optimiser also considers each imported INLINABLE overloaded function, and specialises it for the different types at which it is called in M. ... Moreover, given a SPECIALIZE pragma for a function f, GHC will automatically create specialisations for any type-class-overloaded functions called by f, if they are in the same module as the SPECIALIZE pragma, or if they are INLINABLE; and so on, transitively. So GHC should automatically specialize some/most/all(?) functions marked `INLINABLE` ''without'' a pragma, and if I use an explicit pragma, the specialization is transitive. My question is: is the ''auto''-specialization transitive? Either way, I'd like to see the docs updated to answer this question. Specifically, the attached files demonstrate a bug if auto-specialization ''should'' be transitive. Main.hs: {{{ #!haskell import Data.Vector.Unboxed as U import Foo main = let y = Bar $ Qux $ U.replicate 11221184 0 :: Foo (Qux Int) (Bar (Qux ans)) = iterate (plus y) y !! 100 in putStr $ show $ foldl1' (*) ans }}} Foo.hs: {{{ #!haskell module Foo (Qux(..), Foo(..), plus) where import Data.Vector.Unboxed as U newtype Qux r = Qux (Vector r) -- GHC inlines `plus` if I remove the bangs or the Baz constructor data Foo t = Bar !t | Baz !t instance (Num r, Unbox r) => Num (Qux r) where {-# INLINABLE (+) #-} (Qux x) + (Qux y) = Qux $ U.zipWith (+) x y {-# INLINABLE plus #-} plus :: (Num t) => (Foo t) -> (Foo t) -> (Foo t) plus (Bar v1) (Bar v2) = Bar $ v1 + v2 }}} GHC specializes the call to `plus`, but does *not* specialize `(+)` in the `Qux` `Num` instance. (In the attached core excerpt: `main6` calls `iterate main8`. `main8` is just `plus`, specialized for `Int`. So far so good. However, `splus` calls the *polymorphic* `c+`. If auto- specialization is transitive, I expect `c+` to be specialized to `Int`.) This kills performance: an explicit pragma `{-# SPECIALIZE plus :: Foo (Qux Int) -> Foo (Qux Int) -> Foo (Qux Int) #-}` results in ''transitive'' specialization as the docs indicate, so `(+)` is specialized and the code is 30x faster. Is this expected behavior? Should I only expect `(+)` to be specialized transitively with an explicit pragma? Note: this question is different from #5928 for two reasons: 1. I believe that no inlining is occuring, and hence I don't think inlining is interfering with specialization 2. I have `INLINABLE` pragmas on all relevant functions. Note: this question is different from #8668 because I am asking about ''auto''-specialization. This question was originally posted on [http://stackoverflow.com/questions/21502335/transitivity-of-auto- specialization-in-ghc StackOverflow]. As mentioned in the comments of that question, I am intentionally ''not'' fully applying the call to `plus` in Main, contrary to the suggestions in #8099. I'd love to see why I'm getting that behavior as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 18:00:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 18:00:28 -0000 Subject: [GHC] #8775: GHC panic building postgresql-simple Message-ID: <043.6c94d7fdd47f6535a916c3b9ea3680e6@haskell.org> #8775: GHC panic building postgresql-simple ----------------------------------+------------------------------ Reporter: r0ml | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ For: cabal install postgresql-simple (for all versions of postgresql-simple since 0.3) on OSX Mavericks, I get the following: [14 of 32] Compiling Database.PostgreSQL.Simple.ToRow ( src/Database/PostgreSQL/Simple/ToRow.hs, dist/build/Database/PostgreSQL/Simple/ToRow.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-apple-darwin): Prelude.(!!): index too large Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This also failed to build with 7.6.3 for different reasons -- hence I installed and attempted 7.8.1 -- but the failure was more spectacular. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 18:05:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 18:05:56 -0000 Subject: [GHC] #8775: GHC panic building postgresql-simple In-Reply-To: <043.6c94d7fdd47f6535a916c3b9ea3680e6@haskell.org> References: <043.6c94d7fdd47f6535a916c3b9ea3680e6@haskell.org> Message-ID: <058.3541b23e2ee5771685c969e1d91ec159@haskell.org> #8775: GHC panic building postgresql-simple ------------------------------+---------------------------------- Reporter: r0ml | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8743 ------------------------------+---------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #8743 Comment: Thanks for the report, but this is a duplicate of #8743. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 20:28:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 20:28:46 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.a3c209a8e9d03697c9cd5824de3d8be3@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I do think that would work, but it seems a little unprincipled. And, it was a design decision I wasn't prepared to make without discussion. My general thought is that we're (in my humble opinion) heading to a future where the kind parser and the type parser are no longer distinct, because types and kinds will no longer be distinct. What does parsing in that world look like? I don't know, but I think we should try to future- proof any decision made here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 20:32:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 20:32:32 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.28a7c87249b023d5e38e5be24c865e7a@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by iduhetonas): I had this issue when compiling with libgmp3-dev 2:4.3.2, which was in the repository of Ubuntu 10.04 Lucid. I upgraded to libgmp3-dev 2:5.0.2 in Ubuntu 12.04 Precise, did "make distclean && make maintainer-clean", and recompiled from scratch, which fixed the issue. I assume the error lies between these two versions, so make sure you're using libgmp3-dev 2:5.0.2 at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 20:35:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 20:35:53 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.4ea214444e1c2de6b6343173da904b79@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by slyfox): ghc-7.8.1_rc1-fix-UNREG-system-ffi.patch fixes failure to build working UNREG compiler when you use non-default path to libffi. libdir was already encoded there, but not include dir. Gentoo installs libffi to: /usr/lib64/libffi-3.0.13/ /usr/lib64/libffi-3.0.13/include/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 21:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 21:48:34 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT Message-ID: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> #8776: Displaying pattern synonym for a GADT ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Define {{{ {-# LANGUAGE PatternSynonyms, GADTs #-} data A x y where B :: A x x pattern P = B }}} and in GHCi we see {{{ ?> :i P pattern (t ~ t) => P :: A t t1 -- Defined at X.hs:5:9 }}} It should be `(t ~ t1)`. Just a problem with displaying, the pattern works correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 12 22:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Feb 2014 22:45:32 -0000 Subject: [GHC] #8777: Ghc crashes when compiling happstack-server on ubuntu-docker Message-ID: <049.9f5a3c230d6db444a5c786a9f5a57b59@haskell.org> #8777: Ghc crashes when compiling happstack-server on ubuntu-docker ------------------------------------+------------------------------------- Reporter: timthelion | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am trying to install a package that requires happstack on docker. I recieved the following error: {{{ src/Happstack/Server/Internal/Socket.hs:61:7:ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): Can't happen: pprExp (CompExp []) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It appears I am not the first to receive this error as I found the following paste on lpaste: http://lpaste.net/report/99343 This bug is hard to reproduce. I tried making a minimal case for it in which only haskell-platform was installed. In the minimal case, ghc DOES NOT crash. This works: {{{ FROM ubuntu RUN apt-get update RUN apt-get install -y haskell-platform RUN cabal update RUN cabal install --global happstack-server-7.3.3 }}} However, if you run the following docker file, ghc will crash: {{{ FROM ubuntu RUN apt-get update RUN apt-get install -y haskell-platform git libghc-terminfo-dev libghc- haskeline-dev RUN cabal update RUN git clone --branch dev https://github.com/evancz/Elm.git RUN git clone --branch dev https://github.com/evancz/elm-repl.git RUN git clone https://github.com/evancz/elm-get.git RUN cd Elm; git checkout a815b2fbd00e76c0109b1ab916fe5d0eb184648c RUN cd elm-repl; git checkout 6ab74981363e8e7fabc05083539891568e3c4f17 RUN cd elm-get ; git checkout c67a8ba285f6bfde0a520da1552c4c3443cfab8e RUN cabal install --global Elm elm-repl elm-get Elm/server }}} Crashes with attached output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 06:37:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 06:37:40 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.0f08e01e1f7030206a487882860889cc@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I discovered an interesting flaw in the current design while debugging a segfault today. The problem goes like this: currently, on a per-module basis we generate an extra C file responsible for registering staticclosureinds with the initialization loop which will run at the beginning of the file. The implicit assumption being made here, of course, is that a statically linked module will be loaded atomically together, all of the object files being brought in for the ride. However, this is NOT TRUE when split objects are being used! In this case, it is quite possible for the object file containing the initialization function to *not* be loaded, while another split object which uses an indirection does get loaded. In this case, the static closure never gets initialized, and we'll get a segfault if we try to use it. How can we fix this? One possibility is, when splitting objects, to ensure if the staticclosureinds section is nonzero, then we have a reference to the initialization function somewhere else in the resulting object file, so it gets loaded in. However, it's not even clear that the starts/ends trick is going to even keep working, unless the splitter is very careful. Another possibility is to axe the initialization function, and try harder to detect the staticclosureinds section at runtime. Doing this properly in a cross-platform way is tricky (I originally tried to do it with linker scripts, but gave up when it (1) didn't work, and (2) wasn't going to work on other platforms.) I'll upload an up-to-date patchset for GHC 7.8 at some point. There's been a recent change to integer-gmp which needs to be updated for HEAP_ALLOCED. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:07:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:07:52 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.133069f009c16e1fa992a268821ce901@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by slyfox): With minor tweaks I've got ghci on ppc64 running: {{{ timberdoodle ghc-7.8.20140130 # inplace/bin/ghc-stage2 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","powerpc64-unknown-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","/usr/bin/powerpc64-unknown-linux-gnu-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchPPC_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","YES") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.20140130") ,("Booter version","7.4.2") ,("Stage","2") ,("Build platform","powerpc64-unknown-linux") ,("Host platform","powerpc64-unknown-linux") ,("Target platform","powerpc64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","NO") ,("Tables next to code","NO") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/var/tmp/portage/dev- lang/ghc-7.8.1_rc1/work/ghc-7.8.20140130/inplace/lib") ,("Global Package DB","/var/tmp/portage/dev- lang/ghc-7.8.1_rc1/work/ghc-7.8.20140130/inplace/lib/package.conf.d") ] timberdoodle ghc-7.8.20140130 # inplace/bin/ghc-stage2 --interactive GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 2^128 340282366920938463463374607431768211456 Prelude> }}} The tweak is to build '''compiler/HsExpr.lhs''' as '''ghc --make -O''' instead of '''ghc --make -O2'''. That makes C compiler happy. I think it makes sense to downgrade down to '''-O''' on all UNREG arches, as C cources are already too big to produce code of sane size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:11:20 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.03790bd3b31a1e141d7f5fceb64991f1@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Iceland_jack): I removed `mapCatMaybes`, `allMaybes` and `maybeToBool` completely from `Maybes`, I decided to keep `firstJust` since the name is clearer than `msum` (should `orElse` be moved to `Data.Maybe`? it seems to be the sole reason for importing `Maybes` much of the time). Did you have any other modules in mind that needed cleanup? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:14:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:14:00 -0000 Subject: [GHC] #8778: Typeable TypeNats Message-ID: <047.b9d30639552108a8bde373a259728a9f@haskell.org> #8778: Typeable TypeNats -------------------------------------------+------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 4385 | Test Case: | Blocking: -------------------------------------------+------------------------------- It would be useful (the case I have at hand is for some scenarios involving checking of physical dimensions) to be able to combine the Data.Dynamic story with the GHC.TypeLits story. A Typeable instance for every Nat is the sticking point. (I do not know if this is even theoretically possible.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:14:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:14:25 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.a1d2c245284c7795c58cd4337a0d8173@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Iceland_jack): Couldn't `MaybeT` simply be replaced with `Either`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:37:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:37:11 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.9f672e6321a87692458aa40a70b5ab40@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by BjornBuckwalter): * cc: bjorn.buckwalter@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 08:44:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 08:44:14 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.bbd721e9f10cf6b11024d56d3cd7fa98@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: nomeata Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by nomeata): * owner: => nomeata Comment: I don?t think we should be moving stuff to `Data.Maybe` just yet. Also, the non-monadic versions are easier to read, just as you say. I think the patch is good to go. I?ll validate and push. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 09:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 09:00:17 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.c2985365708ab7691ed2f6013cd4c10a@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by carter): @dmcclean could you please explain what you mean? Make up some pseudo code please! Are you thinking about type level existentials? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 09:12:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 09:12:37 -0000 Subject: [GHC] #8769: Minor refactoring of Maybe.lhs In-Reply-To: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> References: <051.6260bf796f7ab0187df3ce18d1dacb84@haskell.org> Message-ID: <066.c3f4fb2046b381fda2ea383f6c114cad@haskell.org> #8769: Minor refactoring of Maybe.lhs --------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: nomeata Type: bug | Status: closed Priority: lowest | Milestone: Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 09:40:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 09:40:51 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms Message-ID: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{ initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{ f [] = ... f (xs ::: x) = ... }}} is complete, while {{{ g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{ {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 09:48:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 09:48:15 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.6d892ac9961fc48a814bb07fffa94694@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonpj): Good catch Edward! You are such a star. I am not qualified to comment on solutions (at least not without doing quite a bit of homework), but I am very appreciative. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 10:30:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 10:30:15 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.5f735c72ff84acbcfb8437f8ebbba83a@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by maeder): Don't we have an SED expert that can turn this sed expression into a backward compatible one? Who is the author of this sed expression? It is the only one that requires GNU SED! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 10:41:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 10:41:47 -0000 Subject: [GHC] #8780: abs for IEEE floating point is slightly wrong. Message-ID: <047.7d758a25f9194c7d9c9382206575054a@haskell.org> #8780: abs for IEEE floating point is slightly wrong. ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages. Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 11:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 11:48:02 -0000 Subject: [GHC] #8781: check if GNU nm is realy needed and if so let configure detect gnm Message-ID: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> #8781: check if GNU nm is realy needed and if so let configure detect gnm ----------------------------------+---------------------------------------- Reporter: maeder | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Solaris Keywords: | Type of failure: Building GHC failed Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- building ghc-7.8.20140130 under Solaris fails with a non-GNU nm as follows: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/opt/csw/bin/gcc" --gcc-flag -U__i686 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc- flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/ccs/bin/nm" Can't find "STD_HDR_SIZE" gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 12:41:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 12:41:23 -0000 Subject: [GHC] #8305: ghci macros override built-ins for command expansion In-Reply-To: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> References: <047.fc409110f08eee40d2b732450d9304f1@haskell.org> Message-ID: <062.cd3a98bf35ccecfee4fc7656a38137e4@haskell.org> #8305: ghci macros override built-ins for command expansion -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8113 #3858 -------------------------------------+------------------------------------ Changes (by hvr): * related: #8113 => #8113 #3858 Comment: I just noticed the related ticket #3858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 12:44:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 12:44:35 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.5b4d11599543c782b8d93d623390a2b3@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by slyfox): Setting compiler option down to -O fixe building of complete dunamic ghc/ghci on powerpc64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 12:47:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 12:47:53 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.addaf72434e01d09b482c712369f3267@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by hvr): ...maybe it's easier to express that operation in terms of `awk`? For convenience, here's a copy of `sed` script in question: {{{ /hs$$$$/ p ; /hs$$$$/ s/o /hi /g ; /hs$$$$/ s/:/ : %hi: %o / ; /hs$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/ ; /hs$$$$/ s/$$$$/))/ ; /hs-boot$$$$/ p ; /hs-boot$$$$/ s/o-boot /hi-boot /g ; /hs-boot$$$$/ s/:/ : %hi-boot: %o-boot / ; /hs-boot$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/ ; /hs-boot$$$$/ s/$$$$/))/' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:15:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:15:11 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.23c85ae56742a4655c91f2efbcaaf49c@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by maeder): awk is currently not used for building (see attached log file of #8781) and maybe awk is not always GNU awk, too. (But GNU awk is detected by configure.) In any case, I think, this sed script should be more comprehensible for the open source community. Maybe splitting this into several sed calls would do the same job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:23:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:23:04 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.725e902b36c91fd4c4d64bc0e1ba11e1@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kgardas): IMHO it would be the best option to replace the sed expression in question with something more POSIX compatible, i.e. something which at least pass thorough non-GNU seds distributed by let say FreeBSD and Solaris. Unfortunately as a long time Solaris user, I have to admit that current state of GHC build system is absolutely cryptic for me and certainly I'm neither sed expert so I'm not able to distil at all what this make/sed combination should do at the end. Otherwise I would provide (or at least try) the fix/patch myself. So if anybody from developers here can help with explanation what exactly is done or even better how exactly is that done, then perhaps me or Christian will be able to fix the expression and test on our Solarises... Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:27:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:27:00 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm (was: check if GNU nm is realy needed and if so let configure detect gnm) In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.0a37b5132bbfe31cdc4217e088fcd1c3@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:30:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:30:33 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.aa71079efa86fb984951aa819099e38b@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): To fix that it's IMHO a matter of extending deriveConstants to also support POSIX nm output. For example with POSIX nm and '-p' option we get very near to what GNU nm provides, but still there are some differences which should be handled by deriveConstants. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:32:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:32:02 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries Message-ID: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I rewrote `compiler/utils/OrdList.lhs` using a GADT to preserve some invariants stated only in comments ? an excellent chance for `ghc` to eat its own proverbial dog food I feel :) The type signatures remain the same so it should be a drop-in replacement but it does use some GHC features that are too recent (closed type families in particular, the `IsList` instance can be removed) making it ineligible for inclusion I believe. hvr on `#ghc` suggested that I submit a patch anyway and that it could be implemented at a later date (they said `ghc` must be able to be compiled by the last two previous major versions), if this is useful then I will translate `Bag.hls` which has the same invariants but more complicated functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:37:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:37:11 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.e6908d986b7ab3e8c03cc8d9ab5e9d28@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Iceland_jack): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:52:02 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.ff3f83be8207ca405517f2147edf44d6@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => * milestone: 7.8.1 => 7.8.2 Comment: I'm punting this to 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:52:16 -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.8813097dce42d6593571629dd5e8b8d8@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.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time performance bug | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => * milestone: => 7.8.2 Comment: I'm punting this to 7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:52:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:52:37 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.ff8cb34cec855c30b18ccbf6df3deedb@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * version: 7.8.1-rc1 => Comment: This isn't going to happen in time for 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:52:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:52:44 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.3078311676c87e949cf4d1e1757efd5a@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.2 Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * version: 7.8.1-rc1 => * milestone: => 7.8.2 Comment: This isn't going to be done in time for 7.8.1 at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:53:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:53:05 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.38c6ecf6ffa9407262a5dc62db45285e@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.2 Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Or, well, unless you propose to add it (very soon), Richard. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 13:53:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 13:53:12 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.a93d4df708b7ab940054b61281ef38ee@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => * milestone: => 7.8.2 Comment: I can't reproduce this it seems (but others seem to have reported it too.) I'm afraid it won't be fixed for 7.8, but most users won't need to build from source anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:03:42 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal In-Reply-To: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> References: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> Message-ID: <062.995dbba668fc829861518cddd784ed5b@haskell.org> #8728: Segmentation fault in Cabal --------------------------------------+--------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: libraries (other) | Version: Resolution: | Keywords: Cabal Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------- Changes (by thoughtpolice): * version: 7.8.1-rc1 => * milestone: => 7.8.2 Comment: I'm afraid it seems I can't reproduce this on my machines and unless a patch comes in, it's unlikely I'll be able to. I'm unfortunately going to have to punt this for 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:06:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:06:12 -0000 Subject: [GHC] #8728: Segmentation fault in Cabal In-Reply-To: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> References: <047.c83bd969dcf80dcb98f4eab57fef2fb1@haskell.org> Message-ID: <062.8b592918655e8b031bc28c11a6b017b3@haskell.org> #8728: Segmentation fault in Cabal --------------------------------------+----------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: libraries (other) | Version: 7.8.1-rc1 Resolution: | Keywords: Cabal Operating System: MacOS X | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+----------------------------- Changes (by thoughtpolice): * version: => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:06:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:06:30 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.af2ee6cce0d7df7b5e5455d2dbf68406@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Crosscompile Operating System: Linux | cross compile failed ncurses Type of failure: Building GHC | setupterm not found failed | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 Comment: Oh dear. If I remember correctly, the problem is that we sort of work- arounded it by commenting out `terminfo` for the Raspberry Pi cross compilers, but never found a real solution. It should be disabled, really (terminfo is only needed by haskeline, and haskeline is only needed by GHCi - which doesn't exist in a cross compilers.) One solution is just commenting out `terminfo` and `haskeline` from `ghc.mk`, I believe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:06:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:06:47 -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.5eb15889751a0b921925f00c6e66b248@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.8.2 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * version: => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:09:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:09:20 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.73291e68965f5964604b17e18f6bfff1@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:09:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:09:45 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.fb9af8e28352a7bd4dcb88f58904bfbb@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:10:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:10:02 -0000 Subject: [GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes In-Reply-To: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> References: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> Message-ID: <062.a4d5af0df8c88a4693e39ace2f56ba79@haskell.org> #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: merge Component: Compiler (Type checker) | Milestone: 7.8.1 Resolution: | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T8758 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:11:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:11:35 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.8c4597f343394ba5d14e14f99db140de@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:11:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:11:49 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.9690b87bea92724263346f9a2ca7c04d@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8745 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:12:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:12:11 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.ac35e2a3af16b848695e60a4f0139de2@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:15:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:15:08 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.e6a4d977ded6911f2ddafc221ee56b20@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:15:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:15:21 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.0152af87a9b59489bc1f29fd1a71ebc2@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------+------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:18:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:18:58 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.0a7e05861965ba55427e760ad525c7e8@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:20:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:20:43 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris Message-ID: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris ------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-i386-unknown- solaris2.tar.bz2 has a ghc-pwd-bindist script containing {{{ #!/bin/sh export LD_LIBRARY_PATH="libraries/directory/dist- install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist- install/build:rts/dist/build:$LD_LIBRARY_PATH" exec "utils/ghc-pwd/dist-install/build/tmp/ghc-pwd" ${1+"$@"} }}} that fails during configure under Solaris with: {{{ checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory /dist-install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:: is not an identifier configure: error: cannot determine current directory }}} see more under http://www.haskell.org/pipermail/glasgow-haskell- users/2014-February/024669.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:24:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:24:34 -0000 Subject: [GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) In-Reply-To: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> References: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> Message-ID: <057.898304b3237d60f7c6b70f88363c372e@haskell.org> #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) ---------------------------------+----------------------------------- Reporter: z9p | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: dlopen dylib so Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+----------------------------------- Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: I have a fix for this anyway in the course of fixing #8736, so I'll go ahead and mark this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:29:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:29:58 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.ca6ea433d1f1eb2781d3bfe6beed7da8@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Nevermind, I'm just forgetting that I'm stupid. I spent a lot of time experimenting and trying to create a minimal test-case where gcc isn't able to inline. Tough it turned out that my premise was wrong all along, it isn't equivalent to inline the code due to the implicit type casts. It so happens that in `scavenge_arg_block` and `scavenge_stack` the `size` argument is of type `nat`. For these two cases the `STATIC_INLINE` and explicit inline methods created exactly identical object files. But for the function `scavenge_PAP_payload` the variable (actually parameter) with the same name `size` had type `StgWord`. To make this even worse confusing, the passed argument to `scavenge_PAP_payload` is of type `StgHalfWord`. Phew. My suggested resolution is to first apply a patch changing the type signature of `scavenge_PAP_payload` to take a `nat` instead of an `StgWord`. I'll attach a patch. After that the original patch should be merge-able without changing the output of the object files. :) ---- Oh god, I wasted *so much time* on this, for what it's worth, here are some gists I produced in the meantime: https://gist.github.com/Tarrasch/8965562 https://gist.github.com/Tarrasch/8966086 https://gist.github.com/Tarrasch/8971992 https://gist.github.com/Tarrasch/8972574 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 14:30:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 14:30:58 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.92b1ac904c0a850cafc10e00dd53b6f1@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:00:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:00:19 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.17e41bbe5368422010467da322bbecb5@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Ok. I stumbled upon the same exact set of issues with non-matching types for `Compact.c`. It seems like at differenct places `StgWord`, `W_` and `nat` is used. And again `scavenge_PAP_payload` gets passed `StgHalfWord`s. If I were to unify these to use the same type for the variable `size`, which should it be? I would myself just go for `StgWord` since if you look at the `bitmap` variable, it's usually of type `StgWord`, and usually the equation is that `size == BITMAP_SIZE(bitmap) == ((bitmap) & BITMAP_SIZE_MASK)`. Am I over-thinking this? I just think that with these series of patches we get these two nice benefits: 1. A consistent use of the types (or is there any good reason they differ so much?) 2. We can safely apply two patches that would remove a total of 30 lines of code. Without worrying that we loose performance since the `.o` files can be checked to be exact matches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:00:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:00:43 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.fe489681f69610895d2dfc3ad429abfe@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------ Reporter: Iceland_jack | Owner: Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): Yay! I've been wanting to do this sort of thing for some time, but always had more pressing things on my plate. Yes, we absolutely need to keep GHC compiling with the previous two major versions. BUT, I think at this point, that includes down to 7.4, which has !DataKinds. (I wouldn't use 7.4's !PolyKinds so much, but simple promoted datatypes worked well.) For something like closed type families, you could always keep your newfangled implemented in, but commented out, with a note to switch the implementations at a later date. The particular closed type family in your patch is easily written as an open one, so there's no need to delay the whole patch, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:01:16 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.786ad1bc15a3b86a03b7d2f214f170d3@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: 8773 | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * blockedby: => 8773 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:04:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:04:32 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.aee2465fd42ebe7abddc4c16219e2d3b@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.2 Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): No. My thought is that the TH interface should (barring some large disaster) remain stable from the RC to the released version. That way, packages that use TH can test against the RC and be confident that their code will work against the release. Even if I were to implement it today (no plans to), I wouldn't recommend merging. I created the ticket just as a reminder (to anyone) that this should be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:27:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:27:07 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.1d70e77644b78449189ce3debdb3100a@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:28:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:28:22 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.2601107e6faedd773f1705d075ec4dcf@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 15:38:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 15:38:52 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.b62d918c87237e7ab2421e147ac7a0bc@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Crosscompile Operating System: Linux | cross compile failed ncurses Type of failure: Building GHC | setupterm not found failed | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Visionstar): Thank you very much for your response! i somehow managed to go past this 'bug' by doing the following: I configured the ncurses library like this: {{{ ./configure arm-linux-gnueabihf --with-gcc=arm-linux-gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/usr/arm-linux-gnueabihf --with- shared --host=arm-linux-gnueabihf --with-build-cpp=arm-linux-gnueabihf-g++ }}} Afterwards i did the "make" and added it to the path Then i used the ./configure with an "sysroot" command command for GHC like this: {{{ --target=arm-linux-gnueabihf --with-gcc=arm-linux-gnueabihf-gcc --with- shared --enable-unregisterised }}} Which probably didn't change anything, but it got me past that problem with ncurses. '''''But''''' i have now another problem: i get the following error when i try to 'make' the application: {{{ when making flags consistent: Warning: Compiler unregisterised, so compiling via C <> echo "compiler_stage2_depfile_haskell_EXISTS = YES" >> compiler/stage2/build/.depend-v-dyn.haskell.tmp for dir in compiler/stage2/build/./ compiler/stage2/build/CodeGen/ compiler/stage2/build/CodeGen/Platform/ compiler/stage2/build/Hoopl/ compiler/stage2/build/Llvm/ compiler/stage2/build/LlvmCodeGen/ compiler/stage2/build/PPC/ compiler/stage2/build/RegAlloc/ compiler/stage2/build/RegAlloc/Graph/ compiler/stage2/build/RegAlloc/Linear/ compiler/stage2/build/RegAlloc/Linear/PPC/ compiler/stage2/build/RegAlloc/Linear/SPARC/ compiler/stage2/build/RegAlloc/Linear/X86/ compiler/stage2/build/RegAlloc/Linear/X86_64/ compiler/stage2/build/SPARC/ compiler/stage2/build/SPARC/CodeGen/ compiler/stage2/build/Vectorise/ compiler/stage2/build/Vectorise/Builtins/ compiler/stage2/build/Vectorise/Generic/ compiler/stage2/build/Vectorise/Monad/ compiler/stage2/build/Vectorise/Type/ compiler/stage2/build/Vectorise/Utils/ compiler/stage2/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage2/build/.depend-v-dyn.haskell.tmp > compiler/stage2/build/.depend-v-dyn.haskell.tmp2 sed '/hs$/ p ; /hs$/ s/o /hi /g ; /hs$/ s/:/ : %hi: %o / ; /hs$/ s/^/$(eval $(call hi-rule,/ ; /hs$/ s/$/))/ ; /hs-boot$/ p ; /hs-boot$/ s/o-boot /hi-boot /g ; /hs-boot$/ s/:/ : %hi- boot: %o-boot / ; /hs-boot$/ s/^/$(eval $(call hi-rule,/ ; /hs- boot$/ s/$/))/' compiler/stage2/build/.depend-v-dyn.haskell.tmp2 > compiler/stage2/build/.depend-v-dyn.haskell "rm" -f utils/haddock/dist/build/.depend.c_asm.tmp "rm" -f utils/haddock/dist/build/.depend.c_asm.bit echo "utils/haddock_dist_depfile_c_asm_EXISTS = YES" >> utils/haddock/dist/build/.depend.c_asm.tmp mv utils/haddock/dist/build/.depend.c_asm.tmp utils/haddock/dist/build/.depend.c_asm "rm" -f utils/haddock/dist/build/.depend.haskell.tmp "inplace/bin/ghc-stage1" -M -static -H32m -O -fasm -Rghc-timing -hide- all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140204 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -dep-makefile utils/haddock/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg- deps utils/haddock/driver/Main.hs utils/haddock/src/Documentation/Haddock.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/ByteString.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/ByteString/Char8.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/Combinator.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/Number.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/ByteString/FastSet.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/ByteString/Internal.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/Internal.hs utils/haddock/vendor/attoparsec-0.10.4.0/Data/Attoparsec/Internal/Types.hs utils/haddock/src/Haddock.hs utils/haddock/src/Haddock/Interface.hs utils/haddock/src/Haddock/Interface/Rename.hs utils/haddock/src/Haddock/Interface/Create.hs utils/haddock/src/Haddock/Interface/AttachInstances.hs utils/haddock/src/Haddock/Interface/LexParseRn.hs utils/haddock/src/Haddock/Interface/ParseModuleHeader.hs utils/haddock/src/Haddock/Parser.hs utils/haddock/src/Haddock/Parser/Util.hs utils/haddock/src/Haddock/Utf8.hs utils/haddock/src/Haddock/Utils.hs utils/haddock/src/Haddock/Backends/Xhtml.hs utils/haddock/src/Haddock/Backends/Xhtml/Decl.hs utils/haddock/src/Haddock/Backends/Xhtml/DocMarkup.hs utils/haddock/src/Haddock/Backends/Xhtml/Layout.hs utils/haddock/src/Haddock/Backends/Xhtml/Names.hs utils/haddock/src/Haddock/Backends/Xhtml/Themes.hs utils/haddock/src/Haddock/Backends/Xhtml/Types.hs utils/haddock/src/Haddock/Backends/Xhtml/Utils.hs utils/haddock/src/Haddock/Backends/LaTeX.hs utils/haddock/src/Haddock/Backends/HaddockDB.hs utils/haddock/src/Haddock/Backends/Hoogle.hs utils/haddock/src/Haddock/ModuleTree.hs utils/haddock/src/Haddock/Types.hs utils/haddock/src/Haddock/Doc.hs utils/haddock/src/Haddock/Version.hs utils/haddock/src/Haddock/InterfaceFile.hs utils/haddock/src/Haddock/Options.hs utils/haddock/src/Haddock/GhcUtils.hs utils/haddock/src/Haddock/Convert.hs when making flags consistent: Warning: Compiler unregisterised, so compiling via C utils/haddock/src/Haddock/InterfaceFile.hs:85:2: error: #error Unsupported GHC version #error Unsupported GHC version ^ <> make[1]: *** [utils/haddock/dist/build/.depend.haskell] Fehler 1 make: *** [all] Fehler 2 }}} I don't really know what to do with this error, because i thought that 7.8.0 is supported for crosscompiling, but now i get an unsupported ghc version error? Could you tell me how to come over this error or how to bypass/workaround it? Greetings, Edi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:00:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:00:05 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.899b1327a263da00ffff0320ec365eeb@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by kgardas): * version: 7.9 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:28:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:28:41 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.8e8762a51961aeccc1a2a28101199576@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Comment (by dmcclean): Sorry about that, thoughtpolice, I was thinking the field was for where I saw it. Example (also attached, but here for discussion): {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} module Test8778 where import GHC.TypeLits import Data.Dynamic data Phantom (n :: Nat) = Phantom desirable = toDyn (Phantom :: Phantom 3) }}} Results in: {{{ No instance for (Typeable 3) arising from a use of `toDyn' In the expression: toDyn (Phantom :: Phantom 3) In an equation for `desirable': desirable = toDyn (Phantom :: Phantom 3) Failed, modules loaded: none. }}} This is unfortunate because it means that you can't use Data.Dynamic with any types that have phantom Nat parameters. Up a couple of levels in the abstraction hierarchy, this makes it difficult to build a user interface that works well with displaying signals and taking input of arbitrary dimensional types (lengths, velocities, currents, and the like). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:32:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:32:35 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.de337e7f4ecff306cf4db3a34ac1105a@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8759 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8761 ---------------------------------------+----------------------------------- Changes (by goldfire): * version: 7.7 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: Putting this on Austin's radar for 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:33:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:33:33 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.8e33729ba0668a7840db80831adeb61d@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple deriving/should_compile/T8631 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * version: 7.7 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: Putting this on Austin's radar for 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:34:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:34:35 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.f9527965e3609f4b51f0436b1788f2cb@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * version: 7.7 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: Putting on Austin's radar for 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:34:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:34:53 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.30925a58fe849d2794c57c76571df1c2@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * version: => 7.8.1-rc1 Comment: Actually I was sort of reclassifying the tickets and that was my mistake to remove the version :) I've changed it back. And thank you for the example! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 16:55:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 16:55:25 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.0bd6c636d3c92110d5affa7adc6af286@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5682 -------------------------------------+------------------------------------ Comment (by goldfire): I'm working on #5682, but I would think that `Typeable` instances for data constructors exported from base should also be exported from base. Otherwise, there will be orphan instances that might conflict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 17:13:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 17:13:51 -0000 Subject: [GHC] #8784: Makefile missing a dependency Message-ID: <047.02c873519443f94d12a1203e5f65b8e5@haskell.org> #8784: Makefile missing a dependency ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I updated from 8e303d7 (full built, using `devel2`) to 3477216. My build (started with plain `make`) then died with {{{ HC [stage 0] ghc/stage1/build/tmp/ghc-stage1 Undefined symbols for architecture x86_64: "_ghczm7zi9_CallArity_callArityAnalProgram_closure", referenced from: _r9qt_srt in libHSghc-7.9.a(SimplCore.o) _r9qv_srt in libHSghc-7.9.a(SimplCore.o) "_ghczm7zi9_CallArity_callArityAnalProgram_info", referenced from: _saVG_info in libHSghc-7.9.a(SimplCore.o) ld: symbol(s) not found for architecture x86_64 }}} I was able to fix the problem with a `make maintainer-clean`, but the make system should be able to deal with this I think. In general, I've found that I need to resort to `make maintainer-clean` more often, but that's purely anecdotal and possibly not helpful. I'm on Mac OS 10.8.5, Xcode 4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 17:21:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 17:21:29 -0000 Subject: [GHC] #8778: Typeable TypeNats In-Reply-To: <047.b9d30639552108a8bde373a259728a9f@haskell.org> References: <047.b9d30639552108a8bde373a259728a9f@haskell.org> Message-ID: <062.bb24d8fec4124cee36f7bd43c571ca9a@haskell.org> #8778: Typeable TypeNats --------------------------------------------+------------------------------ Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 4385 --------------------------------------------+------------------------------ Changes (by dreixel): * cc: iavor.diatchki@? (added) Comment: Iavor has looked into this, so he might have some status update... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 20:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 20:00:25 -0000 Subject: [GHC] #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs In-Reply-To: <045.20216dcc8b13adab2aebca9b575a94de@haskell.org> References: <045.20216dcc8b13adab2aebca9b575a94de@haskell.org> Message-ID: <060.cca78f77681afa1e29cc8a840a93e3c7@haskell.org> #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs -------------------------------------+------------------------------------- Reporter: jkarni | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by jkarni): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 20:02:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 20:02:40 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.03757bd41347d1c79fcae60e935bff06@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5682 -------------------------------------+------------------------------------ Comment (by dreixel): I agree. But currently we can't even define those instances in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 20:11:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 20:11:31 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.e06fd8dbffcd450d308990c4943cc077@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => infoneeded Comment: The fact that this code worked in <= 7.2 is a bug: #5570. I was unable to get the example above to compile on 7.4.2 or 7.6.3. Do you have an example that works with these versions but fails with 7.8? And, yes, the fix to #5570 did change the typing rules for `($)`, but seemingly in a good way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 20:16:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 20:16:11 -0000 Subject: [GHC] #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs In-Reply-To: <045.20216dcc8b13adab2aebca9b575a94de@haskell.org> References: <045.20216dcc8b13adab2aebca9b575a94de@haskell.org> Message-ID: <060.c224081f7e62544a9506696bcc269590@haskell.org> #8771: ASSERT unexpanded in compiler/coreSyn/CoreSubst.lhs -------------------------------------+------------------------------------- Reporter: jkarni | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed Comment: Thanks, applied. {{{ commit 3d9644c2fc705ec80a8a63b0b698d74cd2d49212 Author: Julian K. Arni Date: Wed Feb 12 04:11:31 2014 -0200 Remove space after ASSERT. Which on OS X leaves macro unexpanded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 20:34:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 20:34:42 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.c89a4f31072c93a0f4856d78e3a82b81@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------+------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I just took a look at this and ended up in deeper waters within the type- checker than where I feel comfortable. But I did discover that the bug persists with {{{ {-# LANGUAGE UnboxedTuples #-} module Bug where data Ty a = Int bug :: () -> (# Ty a, () #) bug _ = (# Int, () #) main :: IO () main = do let (# a, b #) = bug () return () }}} Note that there is no `undefined`, and the previous type synonym `Ty` has now become a datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 21:43:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 21:43:39 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.8544966164e292bc3c19c0880b56d318@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Crosscompile Operating System: Linux | cross compile failed ncurses Type of failure: Building GHC | setupterm not found failed | Architecture: Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Visionstar): Replying to [comment:1 thoughtpolice]: > Oh dear. If I remember correctly, the problem is that we sort of work- arounded it by commenting out `terminfo` for the Raspberry Pi cross compilers, but never found a real solution. It should be disabled, really (terminfo is only needed by haskeline, and haskeline is only needed by GHCi - which doesn't exist in a cross compilers.) One solution is just commenting out `terminfo` and `haskeline` from `ghc.mk`, I believe? Thank you for your reply I replied to my own topic, check it out. Also: in which rows do i have to remove haskeline+terminfo? Thanks, Edi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 22:11:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 22:11:45 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.0b59ea39110e69d6780123313d71f224@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8757 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * version: 7.7 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 22:39:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 22:39:48 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.1866bc46ddd3eebfe993eb9d02a7aa39@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): It's absolutely right that the second argument to `($)` must not have an unboxed kind. Because the code for `($)` must move that argument around (pass to the function), so it must know its width, pointerhood ect. But actually it would be ok for the ''result'' of the call `(f $ x)` to be unboxed, because the code for `($)` doesn't mess with the result; it just tail-calls `f`. It's a bit like the call `(error "foo")` which is allowed to have an unboxed type. So `error` has a rather magical type {{{ error :: forall (a:OpenKind). String -> a }}} where the funny quantifier `a:OpenKind` allows `a` to be instantiated to `Int#` as well as to `Int`. So we could regard `($)` as having the type {{{ ($) :: forall (a:*) (r:OpenKind). (a->r) -> a -> r }}} reflecting the fact that the result kind can range over unboxed types. Unless I'm being stupid here, the fix is simple in `TcExpr`, lines 329-ish: * Remove `b_ty <- newPolyFlexiTyVarTy` * Remove the `unifyType op_res_ty b_ty` * Replace the other reference to `b_ty` with `op_res_ty` Would someone like to try? Of course this deserves an elaboration of `Note [Typing rule for ($)]`, and a reference to this ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 22:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 22:47:41 -0000 Subject: [GHC] #8777: Ghc crashes when compiling happstack-server on ubuntu-docker In-Reply-To: <049.9f5a3c230d6db444a5c786a9f5a57b59@haskell.org> References: <049.9f5a3c230d6db444a5c786a9f5a57b59@haskell.org> Message-ID: <064.68e051db6d6769b1813e78d72bb32d07@haskell.org> #8777: Ghc crashes when compiling happstack-server on ubuntu-docker -------------------------------------+------------------------------------ Reporter: timthelion | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: Closing as 'fixed' since the issue is fixed in upcoming template- haskell-2.9: https://github.com/ghc/packages-template- haskell/commit/d7b864b7ddb0e8c2f58d08dfd50e843eb8966b90 However, that fix will be present only in GHC 7.8, AFAIK 7.6 (or 7.4) is not going to have another bugfix release. Probably you can pester happstack's maintainers, a workaround should be easy. PS. Regarding reproduction: `pprExp 0 (CompE [])` in GHCi with TH should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:02:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:02:24 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.d98d178802b498d5a4f0f2ffe8f72171@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): We don't even need full GADTs: {{{ data A x y = (Num x, Eq y) => B pattern P = B }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:10:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:10:03 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.012e3160657ddc99d53307166e342fff@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 Blocking: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"473f12a3be27a00b035f1fdc7050a0ff31bf12ff/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="473f12a3be27a00b035f1fdc7050a0ff31bf12ff" Fix #5682. Now, '(:) parses. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:10:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:10:03 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.036b875bb61140161d76c0396ffc68d8@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 8745 | Related Tickets: #8745 -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"138297585f88351352e0ed878b25f26e1d6edfef/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="138297585f88351352e0ed878b25f26e1d6edfef" Fix #8773. To make a role annotation on a class asserting a role other than nominal, you now need -XIncoherentInstances. See the ticket for more information as to why this is a good idea. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:11:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:11:50 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.b56005b7cbf9baf1d7241d09c13d0eb6@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 Blocking: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * milestone: 7.6.2 => 7.8.1 Comment: All set here -- I see no reason not to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:12:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:12:56 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.511695f255df42faf85cebffac367d94@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.3 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => parser/should_compile/T5682 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:14:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:14:21 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.d24e6de090481064241c525395124233@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions --------------------------------------------+------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_fail/T8773 | Difficulty: Unknown Blocking: 8745 | Blocked By: | Related Tickets: #8745 --------------------------------------------+------------------------------ Changes (by goldfire): * status: new => merge * testcase: => roles/should_fail/T8773 Comment: I think (once again) that GND and `coerce` are Safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:14:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:14:59 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.333cd3ce54c06a1985f284a2956d18d0@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * blockedby: 8773 => Comment: #8773 fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:17:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:17:00 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.9c2c21bb48c8b44ff2e0c35f538ba26a@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 5682 -------------------------------------+------------------------------------ Comment (by goldfire): #5682 is now fixed in HEAD, so these instances should indeed be definable. I suppose we can be sure that users don't define instances (because they wouldn't parse), so if this gets fixed in time in `base`, that might be mergeable into 7.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:18:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:18:47 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.c2a91f265e6869e6a850544f6b7e1378@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by goldfire): * version: 7.3 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 13 23:47:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Feb 2014 23:47:48 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.c5c31b07bfc0d9fad3d0e9022e358d73@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by George): Right, the important point of the ticket is the regression for [Integer] but implicit in mentioning the order of magnitude improvement for [Int] is the question of why [Integer] is, even after this bug is fixed, an order of magnitude slower than [Int] and would it be possible to make the time for [Integer] much closer to [Int]. After all length only traverses the spine of the list so why the big difference? This is probably obvious to many but not to me and I'd like to know why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 07:56:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 07:56:56 -0000 Subject: [GHC] #8266: Dynamic linking on Mac In-Reply-To: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> References: <052.ca24572fd2de5137d71c0e2e0848107f@haskell.org> Message-ID: <067.1247c8856c7de46f2baa0b8f81aa8e73@haskell.org> #8266: Dynamic linking on Mac --------------------------------------------+------------------------------ Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by hvr): Replying to [comment:57 thoughtpolice]: > Merged. We'll need to update Cabal submodule in HEAD and 7.8 when we do the actual release. For the record; there's nothing left to do for this ticket in particular, as `ghc-7.8` already contains the fix as of 37d6e2c54f117f0a65f3032b6f30b6878b3f6f58 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 08:40:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 08:40:25 -0000 Subject: [GHC] #8785: Replace hooks API in the RTS with something better Message-ID: <047.cfaec68e96673ab1544c0369207069d6@haskell.org> #8785: Replace hooks API in the RTS with something better ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see `compiler/main/SysTools.lhs`) and it apparently doesn't work at all on Mac (#8754). So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (`-rtsopts` etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 08:42:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 08:42:09 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.3279e2eb15780381a3f580fec7ba566b@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): `StgWord` is better than `nat`, being of a known size. Could you do it the other way around? (sorry for making this take even longer) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 08:54:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 08:54:56 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.c2b2e4fd3b7c775a136d0d14b5f57bf8@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Simon - just to allay any confusion, this is a patchset that Edward is working on that isn't currently in GHC, so the bug that he found is not a GHC issue. Edward: we must have to solve this same problem for the initialisation sections that create !StablePtrs for foreign exports, and register cost centres for profiling. I don't remember exactly what we do there, but we probably ought to do it the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:00:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:00:36 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.4e4e4da86038865e92cbfbb39190c14d@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): hvr, your analysis is a bit misleading: In GHC 7.6.3 we have {{{#!haskell intlen1 :: [Integer] intlen1 = enumDeltaToInteger intlen4 intlen4 intlen2 intlen :: Int intlen = case $wlen @ Integer intlen1 0 of ww { __DEFAULT -> I# ww } }}} and in 7.9 we have {{{#!haskell intlen1 :: Int# -> Int intlen1 = enumDeltaToIntegerFB @ (Int# -> Int) (incLen @ Integer) I# intlen4 intlen4 intlen2 intlen :: Int intlen = intlen1 0 }}} Note how the `intlen1` do not directly correspond to each other. So we have a case of successful list fusion that does ''not'' speed up the program. The two `enumDeltaToInteger...` functions (at the end of source:base/GHC/Enum.lhs) are almost the same; both call auxiliary functions, the only difference is whether `:` is used, or an explicitly passed `c`. I believe the problem is that we are using `enumDeltaToIntegerFB` in a higher order way (note the `Int# -> Int`), which allocates partial function applications ? basically the same that happens when `foldl` is implemented with `foldr` (#7994). The fix for that would to make sure that stuff is inlined far enough for the `go` from `up_fb` can be visible (as it is for `Int` in comment:1). It could be related to this comment with `Int` (or not, because inlining does not even go that far): {{{#!haskell {-# INLINE [0] eftIntFB #-} eftIntFB :: (Int -> r -> r) -> r -> Int# -> Int# -> r eftIntFB c n x0 y | isTrue# (x0 ># y) = n | otherwise = go x0 where go x = I# x `c` if isTrue# (x ==# y) then n else go (x +# 1#) -- Watch out for y=maxBound; hence ==, not > -- Be very careful not to have more than one "c" -- so that when eftInfFB is inlined we can inline -- whatever is bound to "c" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:15:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:15:50 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.8f0d7f15f332e37e61732da3bacf0eff@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Ok, with this change (i.e. a special `eftIntegerFB`) I get good results: Run time decreases from 16.3s in 7.6.3 to 11.7s in GHC HEAD. But if I use `-fno-call-arity` (Call arity analysis is not in 7.8), I still get 23s, which is still a regression over 16s, but better than the 30 I got with the unmodified library code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:28:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:28:43 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.6410b694e73a81afea110daa43cbcc41@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by simonmar): @rwbarton diagnosed it correctly. The problem is that * when we compile objects for dynamic linking, references to symbols in the same package are static references, resolved when we link the dynamic library together. * But in GHCi, we are not loading all the modules together, we're loading only the modules we need to satisfy the dependencies of the current expression, linked together as a shared library. If we need more modules later, we link those as a separate shared library, which breaks the assumption that all the objects of a package are linked into the same shared library. In the test case. T8696A is loaded first, then when we try to load T8696B we can't resolve the reference to T8696A because it is in a different shared library. We can link *all* the objects together, regardless of what we actually depend on, and load the whole shared library (and all the package dependencies). The problem with this is that when compiling multiple modules with TH we'll end up loading O(n^2) the number of modules. Unloading doesn't work with dynamic linking. Sigh. I hate dynamic linking. This all used to work properly before. I've run out of time for this today, but there isn't an obviously right solution so it needs a bit more thought anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:31:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:31:33 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.7333bfebce02832e662c02ddd1fb4137@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): The same is achieved with a much simpler change, namely the rule {{{ "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 }}} now I get 11.7s with `-fcall-arity` and 19.7s without, which is quite close the original 11.7s, and non-invasive enough to go into 7.8, I?d say. I?ll prepare a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:38:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:38:44 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.3ec99908e87d0e5894fc2a793acde328@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by nomeata): > Thorough cleaning helps. Sorry, no further clues. Had it again. Just cleaning base helps a well, which is at least faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 09:39:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 09:39:33 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.efb94d8b111d2ce716b0de1ac8d4594d@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * owner: => nomeata * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:09:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:09:27 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.35be6da615d6bfa038033a784878cc01@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Hello Simon, I'll be more than happy to change the uses of `size` to use type `StgWord`, tough I start realizing that such patch can become quite big if I go outside of `Scav.c`. For example, in `Compact.c`, there is a usage of `closure_sizeW_` which have a return type of `nat`. My best judgement says that I should change it to return of type `StgWord`, but since it's such a big and used function it might affect other parts of the code. Am I in the right direction? Regardless I think that this effort to unify the types is beneficial, because at many of these in-lined call sites there are implicit type conversions which cost cycles performance. ''We'' know that the `size` will always fit in 32 bits, but gcc doesn't. So, would a patch including a change of `nat closure_sizeW_` to `StgWord closure_sizeW_` be a good idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:14:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:14:14 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.b30662e95d3c43ac299d3f6e7f3ee440@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * owner: => Tarrasch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:17:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:17:00 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.bd097e687f6da4b4c2e4f914814139aa@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"a60eeccf06c28bee3b87c561450320d17c7399e3/base"]: {{{ #!CommitTicketReference repository="base" revision="a60eeccf06c28bee3b87c561450320d17c7399e3" Improve list fusion for [n::Integer..m] enumFromTo for Integers goes via enumDeltaToInteger, which is less efficient, as the "delta > = 0" check prevents more inlining which is required for good fusion code. This rule avoids tihs check for the common case of "delta = 1", makes up_fb visible and hence inlineable, which greatly improves "length [n:Integer..m]"; even more so with CallArity enabled. (#8766) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:17:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:17:01 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.fd8f484487d0fff89b13176a1dfe65d2@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Joachim Breitner ): In [changeset:"d455e2dfb6d1a7b4b22784f0c49178bd346e15e0/base"]: {{{ #!CommitTicketReference repository="base" revision="d455e2dfb6d1a7b4b22784f0c49178bd346e15e0" Test case for #8374 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:18:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:18:42 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.73e6b3591f65432637aad6fb562d7656@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by Joachim Breitner ): In [changeset:"f28ee96d7c246f78d5e8cb9c853f417e54ff3d91/base"]: {{{ #!CommitTicketReference repository="base" revision="f28ee96d7c246f78d5e8cb9c853f417e54ff3d91" Wrong bug number the previous commit added a testcase for #8766, not #8374 -- too many tabs open. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:18:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:18:43 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.c8ce69290b4223d32ce36626fb2b5739@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"f28ee96d7c246f78d5e8cb9c853f417e54ff3d91/base"]: {{{ #!CommitTicketReference repository="base" revision="f28ee96d7c246f78d5e8cb9c853f417e54ff3d91" Wrong bug number the previous commit added a testcase for #8766, not #8374 -- too many tabs open. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:20:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:20:38 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.920e98c774ddde2ae1f53db31143a471@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: nomeata Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T8755 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => merge * testcase: => T8755 Comment: Pushed, please merge to 7.8. If you also merge the test case (the first performance test in `libraries/base/tests` ? I hope there was no good reason why there weren?t any before) you probably have to adjust the numbers, unless we also merge the call-arity analysis (which I don?t think has seen enough testing to go into a stable release). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 10:32:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 10:32:28 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.60f9b83cab33f9eca6158655be5d2146@haskell.org> #8199: Get rid of HEAP_ALLOCED ----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: | Keywords: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: 5435 Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I think in both cases, the usage-pattern of the symbols makes things "just work". Maybe this should be documented. In the case of foreign exports, you will usually end up linking the object file containing the init_array, because the exported symbols are in the same object file. This means we don't setup a stable pointer if the exported symbol is never referred to in the linking process, but that's desired behavior. In the case of profiling, functions which SCC emit code using 'emitSetCCC'. This will create a reference to a cost-centre object, which is contained in the object file that also has the init_array. If there are no SCCs in a module, the registration doesn't get run, but that's also desired behavior. So, it would seem that the appropriate thing to do here is ensure that there is an appropriate dependence between object files which have static closures and the initialization code. Frankly, I'm surprised that this isn't the case already; perhaps I need to link together some object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 11:34:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 11:34:35 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.b7dfc310f8ae7501d4921c3b06f066c4@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Don't go crazy here (also, it's not on your critical path!). Yes it would be good to change uses of `nat` to `StgWord`, but there's no hurry. If you want to do that as a separate patch then go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 12:45:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 12:45:51 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.ba03e88d7ae39e5be338c8fd088bae9d@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Hi again, So I added two patches now. One that changes some types of the `size` variable to `StgWord`. This one will naturally affect the assembly. But the second patch which does the code reuse doesn't change the affected object file. ---- For my own reference later: https://gist.github.com/Tarrasch/8976269 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 13:33:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 13:33:20 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.4385aa2b84bec0cb3d16f66bc5f867c3@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by maeder): It has nothing do to with libraries/Cabal/Cabal/Distribution/Simple/Program/Script.hs (although being wrong, too), but is caused by "$$($1_$2_BINDIST_WRAPPER)" in rules /shell-wrapper.mk. The variable $(SHELL) is not the one set by ./configure. prependLibraryPath from rules/library-path.mk creates the non-Bourne export statement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 14:16:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 14:16:44 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.ec661fc17c30e9df4154ef1dbaf7c03f@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by maeder): The $(SHELL) setting from configure is not taken, because mk/config.mk.in contains /bin/sh hard-coded. A fix might be: {{{ -SHELL = /bin/sh +SHELL = @SHELL@ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 14:23:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 14:23:38 -0000 Subject: [GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris In-Reply-To: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> References: <045.7ce26dcb972ffa41139a911d5f5ddf6a@haskell.org> Message-ID: <060.357fe2ad82ad7999b2da8c83d2c115d3@haskell.org> #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris -------------------------------------+------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by maeder): Another fix could be made in rules/library-path.mk {{{ -prependLibraryPath = export LD_LIBRARY_PATH="$1:$$LD_LIBRARY_PATH" +prependLibraryPath = LD_LIBRARY_PATH="$1:$$LD_LIBRARY_PATH"; export LD_LIBRARY_PATH }}} What an adventure discovering the build secrets! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 15:59:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 15:59:15 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.2c8802f34a77949b47efa849f41f5d5d@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------ Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 5144 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): JFTR: The code in master already contains a `PatSynSig` constructor, but it is dead code... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 16:00:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 16:00:33 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.c3aed8ee342a8b1eda1437ba282ee55b@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by dmcclean): * cc: douglas.mcclean@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 17:01:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 17:01:58 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.b1de9dd3e874b2474be34716ba422999@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): I believe, the following works, but still need to test it. {{{ sed -e '/hs$$$$/ p' -e '/hs$$$$/ s/o /hi /g' \ -e '/hs$$$$/ s/:/ : %hi: %o /' \ -e '/hs$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/' \ -e '/hs$$$$/ s/$$$$/))/' \ -e '/hs-boot$$$$/ p' -e '/hs-boot$$$$/ s/o-boot /hi-boot /g' \ -e '/hs-boot$$$$/ s/:/ : %hi-boot: %o-boot /' \ -e '/hs-boot$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/' \ -e '/hs-boot$$$$/ s/$$$$/))/' \ $$@.tmp2 > $$@ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 17:04:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 17:04:41 -0000 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> References: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> Message-ID: <068.10f77dfffde839a31a1901b42ac69ffb@haskell.org> #3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Might be worth trying making `primOpIsCheap` be true more often. Perhaps always true. Perhaps only if not out-of-line. Or perhaps a new property. But we think it ''can'' be true of primops that can fail (like division), especially in lazy contexts like this one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 17:09:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 17:09:56 -0000 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> References: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> Message-ID: <061.1f530aea3a4ae44bf81ea291c879e306@haskell.org> #2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): If we eta-expand to: {{{ h x = let f = \y -> case x of { True -> t1 y; False -> t2 y } in (f,f) }}} then we'd do the `case x` each time we call `f`, rather than once. But in exchange we get better code for `f`. Worth a try perhaps. Notice that we do such things between lambdas: {{{ h x = let g = \y -> case x of { True -> \v->e1; False -> \v->e2 } in ... }}} here we do (already) eta-expand g to {{{ h x = let g = \y v -> case x of { True -> e1; False -> e2 } in ... }}} This seems inconsistent with not doing so in for `f`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 17:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 17:13:37 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.1c0dba412bdb374ad6f42fdb58f3bed8@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MikeIzbicki): It would also be nice to support negative rationals in a clean way. (For example, by typing just -1.3) I'm guessing this would be best done by adding support for integers, then making the rationals use the integers instead of Nats. This might be confusing for the type checker though because it wouldn't know whether a number like 4 was a type int or a type nat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 17:17:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 17:17:43 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.652d41e08b1da9ae2761e1ae773d4565@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by dmcclean): Type integers are highly useful in their own right. They are essential to tracking physical dimensions associated with quantities, because you need to track integer powers of length, mass, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 14 20:37:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Feb 2014 20:37:01 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.687e2b57e010fcb569d59ed5f9221be1@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------ Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): so lets decouple this a teeny bit: a) having good syntactic support for writing numerical literals at the type level: Integers, Nats, Rationals (possibly with floating point style notation) b) having a satisfactory type model underneath that supports the computations you want to do. currently in GHC those two are conflated, and perhaps they should be decoupled! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 01:50:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 01:50:13 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.7f55805a66cd184bf8308a425d4c3e86@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): Using `-dppr-debug` shows that the two type variables are distinct and correct: {{{ pattern (base:GHC.Num.Num{tc 2b} t{tv aQa} [sk], ghc-prim:GHC.Classes.Eq{tc 23} t{tv aQb} [sk]) => main:Main.P{d rs2} :: main:Main.A{tc rpC} t{tv aQa} [sk] t1{tv aQb} [sk] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 02:26:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 02:26:42 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.fd34132f49879fd838ac683d5f440281@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): When you do a `:t P` in GHCi, it runs `PprTyThings.pprPatSyn`, which uses `TypeRep.pprTheta` to print both contexts: {{{ pprPatSyn :: PatSyn -> SDoc pprPatSyn patSyn = pprPatSynSig ident is_bidir args (pprTypeForUser rhs_ty) prov req where ident = patSynId patSyn is_bidir = isJust $ patSynWrapper patSyn args = fmap pprParendType (patSynTyDetails patSyn) prov = pprThetaOpt prov_theta req = pprThetaOpt req_theta pprThetaOpt [] = Nothing pprThetaOpt theta = Just $ pprTheta theta (_univ_tvs, _ex_tvs, (prov_theta, req_theta)) = patSynSig patSyn rhs_ty = patSynType patSyn }}} So it seems to me that the problem is `pprTheta` pretty-printing the context constraint-by-constraint, without any regard to possible name clashes between mentioned type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 02:29:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 02:29:31 -0000 Subject: [GHC] #8776: Displaying pattern synonym for a GADT In-Reply-To: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> References: <047.6c11701a2adbf25870e07d14b7b24e14@haskell.org> Message-ID: <062.945cff7fe62c6020094e9f018eac13ca@haskell.org> #8776: Displaying pattern synonym for a GADT -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by cactus): I am off for next week in an hour and I don't really know my way in the world of `OutputBndr`. If anyone can help based on the diagnosis above, please jump in in time for GHC 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 17:56:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 17:56:58 -0000 Subject: [GHC] #8786: libraries/primitive build failure on Solaris 10 Message-ID: <046.935806b919fa984f3495fcf0b192593a@haskell.org> #8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Solaris 10 is distributed with GNU C 3.4.3 compiler. This compiler does not support -ftree-vectorize command-line option and so its cc1 process fails on it which also mean that ghc-cabal fails compiling primitive package. The solution is simple to remove the -ftree-vectorize for solaris although it'll penalize Solaris 11 which is distributed with GNU C 4.6.2. I've solved that and provided a patch to primitive project in a pull request here: https://github.com/haskell/primitive/pull/6 I've entered the bug here to also track it and lobby for this issue to be solved for 7.8.1 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 19:37:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 19:37:24 -0000 Subject: [GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling Message-ID: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> #8787: compiler/ghc.mk: restore GhcHcOpts variable handling ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- wiki and mk/config.mk.in suggests setting GhcHcOpts for compiler-wide haskell flags. But it does not work for a while now. Proposed patch fixes it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 19:40:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 19:40:47 -0000 Subject: [GHC] #8788: Remove old comment Message-ID: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> #8788: Remove old comment ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See attachment -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 19:44:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 19:44:38 -0000 Subject: [GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' Message-ID: <045.b850527287f5f9a1d5ff3741d2721e19@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Looks like WITHSMP is not generated anywere, thus don't know how it worked before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 19:55:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 19:55:39 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser Message-ID: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For quite a long while you might have seen such ./configure output: {{{ checking bfd.h usability... yes checking bfd.h presence... yes checking for bfd.h... yes ... checking for bfd_uncompress_section_contents in -lbfd... no }}} which means very interesting debug bit in rts (+RTS -Di) is disabled. It's because most of functions in bfd.h are actually macros, thus test fails: config.log: {{{ configure:9545: checking for bfd_uncompress_section_contents in -lbfd configure:9570: x86_64-pc-linux-gnu-gcc -o conftest -march=corei7-avx -mtune=corei7-avx -O2 -pipe -fdiagnostics-show-option -frecord-gcc- switches -ggdb3 -march=corei7-avx -march=corei7-avx -m tune=corei7-avx -mtune=corei7-avx -ggdb3 -fno-stack-protector -Wa,-- noexecstack -Wa,--noexecstack -fno-stack-protector -Wl,-O1 -Wl,--as- needed -Wl,--hash-style=gnu -Wl,--hash-size=31 -Wl,--r educe-memory-overheads conftest.c -lbfd -liberty >&5 /tmp/portage/dev-lang/ghc-7.6.3-r1/temp/ccCEvDZ7.o: In function `main': /tmp/portage/dev-lang/ghc-7.6.3-r1/work/ghc-7.6.3/conftest.c:99: undefined reference to `bfd_uncompress_section_contents' }}} We don't use that function anyways, thus i've picked '''bfd_init'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 19:59:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 19:59:30 -0000 Subject: [GHC] #8788: Remove old comment In-Reply-To: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> References: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> Message-ID: <062.8fa57d68995e3f79b778a8f22c4df879@haskell.org> #8788: Remove old comment -------------------------------+------------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by crockeea): * difficulty: Unknown => Easy (less than 1 hour) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 21:07:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 21:07:46 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations on Int in Data.Bits Message-ID: <042.dafef0a3988131827ed64c838619782e@haskell.org> #8791: Use new primitive bitwise operations on Int in Data.Bits ------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7689 | ------------------------------------+------------------------------------- New primitive bitwise primops have been added (`andI#`, `orI#`, etc). They should be used in the `Int` instance of `Data.Bits` to avoid `I# (word2Int# (int2Word# ...))` conversions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 21:29:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 21:29:22 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations on Int in Data.Bits In-Reply-To: <042.dafef0a3988131827ed64c838619782e@haskell.org> References: <042.dafef0a3988131827ed64c838619782e@haskell.org> Message-ID: <057.a39dc3f79b688d2062364f325d0000b7@haskell.org> #8791: Use new primitive bitwise operations on Int in Data.Bits -------------------------------------+------------------------------------ Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7689 -------------------------------------+------------------------------------ Changes (by cdk): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 21:39:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 21:39:22 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations for Int# in Data.Bits (was: Use new primitive bitwise operations on Int in Data.Bits) In-Reply-To: <042.dafef0a3988131827ed64c838619782e@haskell.org> References: <042.dafef0a3988131827ed64c838619782e@haskell.org> Message-ID: <057.9364793c00dcf6f4d5fe83427444a9ed@haskell.org> #8791: Use new primitive bitwise operations for Int# in Data.Bits -------------------------------------+------------------------------------ Reporter: cdk | Owner: cdk Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7689 -------------------------------------+------------------------------------ Changes (by cdk): * owner: => cdk -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 15 23:27:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Feb 2014 23:27:54 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.2613e8adecc39e6fb8b78cdff6864196@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by charmander): * cc: campersander@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 02:03:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 02:03:30 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc Message-ID: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc ------------------------------------+-------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 02:06:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 02:06:23 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.f4b60bd69280c3eada7ebac0faee8271@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc --------------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by George): From ghc-7.8.20140130/docs/users_guide/users_guide/code-generators.html #llvm-code-gen: To install LLVM and Clang: ... Mac OS X: LLVM and Clang are included by default from 10.6 and later. Apple does not include LLVM (opt and llc are what is needed) by default. They needed to be installed by homebrew or an alternative system. We may want to document that llvm 3.4 is the preferred version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 02:07:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 02:07:30 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.116e058a1900243aeae488a73cd959b8@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by George): * difficulty: Unknown => Easy (less than 1 hour) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 03:00:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 03:00:17 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance Message-ID: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> #8793: Improve GHC.Event.IntTable performance ------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The performance of `GHC.Event.IntTable` can be improved. I've managed to get some nice increases across the board. Benchmarking using `criterion` shows: function, % faster than current impl. `insert`: 4% `lookup`: 26% `update`: 11% `delete`: 5% There is one strange thing I noted. In `updateWith`, there is an inner loop that looks like this: {{{ data Bucket a = Empty | Bucket Int a (Bucket a) go _ Empty = (False, Nothing, Empty) go cont (Bucket key val next) | key == k = case f val of Nothing -> (True, Just val, cont next) Just v -> (False, Just val, cont (Bucket key v next)) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which returns a tuple that is immediately consumed like so: {{{ (delete_occurred, old_val, new_bkt) <- go id ... when (isJust old_val) $ do when delete_occurred return old_val }}} I expected that inlining the `` and `` code blocks directly into `go` would result in better code than creating a tuple and then pattern matching on it afterwards. ie. {{{ go _ Empty = return Nothing go cont (Bucket key val next) | key == k = do case f val of Nothing -> (cont next) >> Just v -> (cont (Bucket key v next) return (Just val) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which has the exact same semantics. To my suprise, this code is almost 2x slower! The core generated in both cases is exactly what I'd expect; if anything, the second version seems tighter. I'm not sure why the first version is faster, but perhaps the original author, Bryan O'Sullivan, can shed some light as he used the tupled method in the first version. I'll attach my patch, `criterion`'s html output for the benchmarks as well as the benchmarking code, and the core for the oddity I discussed above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 03:28:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 03:28:40 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.97fdacea0ff47882e7727395730b581c@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by goldfire): * priority: normal => high * version: 7.7 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: Tweaking settings on the ticket to give it perhaps higher visibility. This bug is a type inference regression that I believe will hit the type system power users and would be embarrassing if we don't fix before the release. I've confirmed that the error happens in 7.8rc1. I haven't put time into looking for the source of the problem, but I think it will be in code I'm not (yet) deeply familiar with. If the release is approaching and this is still around, please ping me and I'll see what I can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 04:49:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 04:49:45 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.1904041e8c5cbe4a7d18a839ece8a138@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------ Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by cdk): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 09:00:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 09:00:40 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.69308f300178c65729d148199afb25d5@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kgardas): Got the same issue like nomeata, but on i386-unknown-solaris platform while trying to compile HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 09:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 09:50:25 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.bd14f05f46db18d6795e47b8184fa18b@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser ----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by trommler): * cc: ptrommler@? (added) * difficulty: Unknown => Moderate (less than a day) Comment: The test for {{{bfd_uncompress_section_contents}}} is there to work around a statically linked libbfd that depends on libz. In that case the test intentionally fails. See #3756. Should we reopen #3756? I could work on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 12:39:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 12:39:04 -0000 Subject: [GHC] #4959: Warning about variables with leading underscore that are used anyway In-Reply-To: <046.bcfe113f172968b7f0a376e02f66b8da@haskell.org> References: <046.bcfe113f172968b7f0a376e02f66b8da@haskell.org> Message-ID: <061.257d09a5f953cd6c493372026bb0503f@haskell.org> #4959: Warning about variables with leading underscore that are used anyway -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 (Parser) | Keywords: warning unused Resolution: | underscore variable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:6 goldfire]: > I don't have too strong an opinion here, but I want to note that sometimes the use of a variable with a leading underscore is intentional. In particular, I have found this necessary when I use CPP to optionally disable a certain chunk. I don't want warnings to appear when I disable the chunk (eliminating the one use of a variable, to which I prepend a `_`) or when I enable the chunk (now using a variable with a leading underscore). Could you move the conditionally used variable into the `#ifdef` block? > So, I have a slight preference for "no change" here, but it really is a slight preference -- I do see and understand the original poster's point. It should be possible to disable the used-underscore-warning. If the CPP problem arises often and is hard to workaround, then it would be still great to enable the used-underscore-warning on demand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 13:24:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 13:24:03 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.ce66d79200b21482f02806ac2ba76b97@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by kgardas): * owner: => kgardas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 13:27:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 13:27:32 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.8290bdb0d31c49cac10eb6223ad379ea@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by kgardas): * status: new => patch Comment: Attached patch fixes that. It basically enhances deriveConstants utility to also support Solaris' nm program. Christian please test it. I've tested it here on Solaris 11.1 and Solaris 10 update 8. I'm using PATH which is set to Single Unix Specification 3 standard, that means nm is taken from /usr/xpg4/bin directory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 13:29:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 13:29:32 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.5eb3b68848f2b1a9872288cd7e69158b@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): BTW: Is this issue a regression? (let's say in comparison with 7.6.x?) If it is, then we may attempt to push it to Austin for inclusion in 7.8.1? If not, then let's wait and ask for merge into HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 13:34:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 13:34:53 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.a0051bb787ab94a8072ef5091b70706f@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): Replying to [comment:7 maeder]: > I believe, the following works, but still need to test it. > {{{ > sed -e '/hs$$$$/ p' -e '/hs$$$$/ s/o /hi /g' \ > -e '/hs$$$$/ s/:/ : %hi: %o /' \ > -e '/hs$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/' \ > -e '/hs$$$$/ s/$$$$/))/' \ > -e '/hs-boot$$$$/ p' -e '/hs-boot$$$$/ s/o-boot /hi-boot /g' \ > -e '/hs-boot$$$$/ s/:/ : %hi-boot: %o-boot /' \ > -e '/hs-boot$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/' \ > -e '/hs-boot$$$$/ s/$$$$/))/' \ > $$@.tmp2 > $$@ > }}} This is great! It works here on both Solaris 11.1 and Solaris 10 update 8! If it also works on other platforms this would be the best solution of this issue IMHO. Thanks for providing it! BTW: Are you able to provide this patch as a Git patch and attach to this ticket? If not, I may do this for you... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 20:23:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 20:23:35 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.8daa48a4df710068c7748b1803e7109a@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by schyler): I thought I'd throw in a note that something naive like "brew install llvm" doesn't actually install the command line tools llc/opt. I haven't actually figured out how to do so using brew. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 20:50:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 20:50:59 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.20f7d9784f1d6b86a711d5c61435cb49@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by George): That's strange, brew install llvm does give me llc and opt. The point of my ticket is that Apple does not supply them so the doc is wrong in that regards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 20:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 20:53:04 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.c1fa551ff49e14919f3148847e394e3d@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): @schyler: yes it dees install them. You just need to make sure you brew linked em and that the ghc settings file points to that version / name variant of the opt and LLC commands. I suspect you just didn't check that. Ghc is not going to be bundled with llvm in the next year. If the ghc user can't install llvm on their machine, they shouldn't use it. That said, Suggestion of the ticket is valid in premise but not in details. For example, ghc iOS needs llvm 3.0 George: where in the docs is the current information you're referring to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 21:29:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 21:29:55 -0000 Subject: [GHC] #8792: apple does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.60ac881df635a349e86d7a2177c7bec0@haskell.org> #8792: apple does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by George): As I said in my first sentence doc location is ../ghc-7.8.20140130/docs/users_guide/users_guide/code-generators.html #llvm-code-gen I don't understand why the details are not valid, I don't talk about iOS just Mac OS X. The doc refers to OS X and is wrong wrt LLVM, correct? When I said llvm 3.4 is the preferred version I meant for MAC OS X and I believe for Windows and Linux which is what this section of the document refers to. I should have written I believe llvm 3.4 is the preferred version for Mac OS X ... Additionally for Mac OS X it should mention that Clang is available from Apple not supplied by default, correct? However you have a good point about llvm 3.0 being the preferred version for 3.0. Thanks for bringing that up, definitely needs to be documented. Is the problem with 3.4 on the llvm side or the Haskell side? Are there other OS that require an earlier version of llvm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 16 21:59:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Feb 2014 21:59:35 -0000 Subject: [GHC] #8792: Mac OS X does not supply lllvm i.e. opt and llc (was: apple does not supply lllvm i.e. opt and llc) In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.0ca39d5e53d84873a12ce7af29837e94@haskell.org> #8792: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 01:22:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 01:22:57 -0000 Subject: [GHC] #8792: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.d505c19acddc80bb3e1295c0b32c7946@haskell.org> #8792: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): {{{ You must install and have LLVM available on your PATH for the LLVM code generator to work. Specifically GHC needs to be able to call the optand llc tools. Secondly, if you are running Mac OS X with LLVM 3.0 or greater then you also need the Clang c compiler compiler available on your PATH. Clang and LLVM are both included with OS X by default from 10.6 onwards. To install LLVM and Clang: Linux: Use your package management tool. Mac OS X: LLVM and Clang are included by default from 10.6 and later. For 10.5 you should install the Homebrew package manager for OS X. Alternatively you can download binaries for LLVM and Clang from here. Windows: You should download binaries for LLVM and clang from here. }}} from http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/code- generators.html#llvm-code-gen ok, so the issue is that the direction for OS X are wrong. It was hard to parse you ticket :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 01:24:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 01:24:24 -0000 Subject: [GHC] #8792: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.aa7e1c37aed835958f1f8a958a8da583@haskell.org> #8792: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): so we should more clearly say "clang is provided on recent OS X, but to use the LLVM backend, you will need to install LLVM, such as by having the homebrew package manager and invoking {{{ brew install llvm }}}" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 02:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 02:00:03 -0000 Subject: [GHC] #8792: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.5a0218aa43602a617a20b26d9b0c4703@haskell.org> #8792: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:8 carter]: > {{{ > > You must install and have LLVM available on your PATH for the LLVM code generator to work. Specifically GHC needs to be able to call the optand llc tools. Secondly, if you are running Mac OS X with LLVM 3.0 or greater then you also need the Clang c compiler compiler available on your PATH. Clang and LLVM are both included with OS X by default from 10.6 onwards. > > To install LLVM and Clang: > > Linux: Use your package management tool. > Mac OS X: LLVM and Clang are included by default from 10.6 and later. For 10.5 you should install the Homebrew package manager for OS X. Alternatively you can download binaries for LLVM and Clang from here. > Windows: You should download binaries for LLVM and clang from here. > > }}} > > from http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/code- generators.html#llvm-code-gen > > > ok, so the issue is that the direction for OS X are wrong. > > It was hard to parse you ticket :) Yes, sorry about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 02:01:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 02:01:08 -0000 Subject: [GHC] #8792: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.ea11bc0bd240fdb5dd60f067be45f619@haskell.org> #8792: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by George): Replying to [comment:9 carter]: > so we should more clearly say "clang is provided on recent OS X, but to use the LLVM backend, you will need to install LLVM, such as by having the homebrew package manager and invoking {{{ brew install llvm }}}" Sounds good, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 03:59:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 03:59:13 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.c9e0cbbcc361911ca97d0bc81b420546@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by khyperia): * cc: echauck@? (added) * status: new => patch Comment: I believe I have fixed this, although this is my second time committing to ghc and first time digging into the build system. Please review appropriately. Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:31 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.8527f320f82ab879930f78996a15debf@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"68f0a6a6cd5bf3374fbc4a4fb09df4cbda97b61c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="68f0a6a6cd5bf3374fbc4a4fb09df4cbda97b61c" Fix --enable-unregistered by passing NOSMP to .hc compiler (#8748) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:31 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.58bb855f187dc377f23573de185f8d81@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"4bb50ed0c6246e2d45e22e79f5658db1fa8a58b3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bb50ed0c6246e2d45e22e79f5658db1fa8a58b3" Fix --enable-unregistered by declaring missing RTS functions (#8748) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:32 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.d44c756c423313a86da8f82a08b6f8dd@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"ebace6969f0ec85b1caa0fea265a5f9990a23b2e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ebace6969f0ec85b1caa0fea265a5f9990a23b2e" rts/Capability.c: fix crash in -threaded mode on UNREG build UNREG mode has quite nasty invariant to maintain: capabilities[0] == &MainCapability and it's a non-heap memory, while other capabilities are dynamically allocated. Issue #8748 Signed-off-by: Sergei Trofimovich Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:32 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.9c9a8d56a9045f0ac437b6f7a3e069e3@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"858a807d5522145e8ede9148a15bb65a0d851c00/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="858a807d5522145e8ede9148a15bb65a0d851c00" includes/Stg.h: add declarations for hs_popcnt and frinds This fixes most of implicit function declarations emitted C codegen in UNREG mode. Found by adding the following to mk/build.mk: SRC_CC_OPTS += -Werror=implicit-function-declaration SRC_HC_OPTS += -optc-Werror=implicit-function-declaration Issue #8748 Signed-off-by: Sergei Trofimovich Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:33 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.7c02d8f4da8808dfd16857b5fb59ab11@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"2d0fa9aee78e5bfffb9a4580954825025a651be5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2d0fa9aee78e5bfffb9a4580954825025a651be5" rts/package.conf.in: fix UNREG on --with-system-libffi when include-dir is passed explicitely Issue #8748 Signed-off-by: Sergei Trofimovich Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:33 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.2232207d4d79b99a0c99de88dcbb6512@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"2d5372cfdc2236a77ec49df249f3379b93224e06/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2d5372cfdc2236a77ec49df249f3379b93224e06" mk/config.mk.in: lower -O2 optimization down to -O1 on UNREG Disable -O2 optimization. Otherwise amount of generated C code makes things very slow to compile (~5 minutes on core-i7 for 'compiler/hsSyn/HsExpr.lhs') And sometimes not compile at all (powerpc64 overflows something on 'compiler/hsSyn/HsExpr.lhs'). Issue #8748 Signed-off-by: Sergei Trofimovich Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:34 -0000 Subject: [GHC] #8735: hpc crashes on platforms using dynamic linking In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.dd1a588aa5ad6dfaf158d468f7eef2e9@haskell.org> #8735: hpc crashes on platforms using dynamic linking ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"a365eabd465a1700f479f78ad99fc1a31915e639/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a365eabd465a1700f479f78ad99fc1a31915e639" Fix installation of hpc (#8735) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:34 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.f2973bcefb9199bbf74d8331cd4a446a@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"5023c91780e90947680fe0640f7564a4f6448bea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5023c91780e90947680fe0640f7564a4f6448bea" Fix #8754 in a round-about way. For some reason on OS X, it seems like -Bsymbolic (which we use for hooks into the RTS) isn't working, which results in #8754, where stats don't work because defaultHooks doesn't initialize the stats flag. This seems to work on Linux static/dynamically, but only on OS X statically. After talking with Simon, really, the entire hooks thing is a bit fragile. For now, we just work around it (since GHCi is dynamically linked) by calling into the defaultHooks ourselves when GHC starts. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:34 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.b7dcb844521d1257754bc5d0b9bf72cb@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Austin Seipp ): In [changeset:"a8a01e742434df11b830ab99af12d9045dfcbc4b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8a01e742434df11b830ab99af12d9045dfcbc4b" Fix #8745 - GND is now -XSafe compatible. As discussed in the ticket, after the landing of #8773, GND is now -XSafe compatible. This fixes the test fallout as well. In particular SafeLang07 was removed following in the steps of SafeLang06, since it no longer failed from GND, but failed due to roles and was thus invalid. The other tests were tweaked to use TemplateHaskell instead of GND in order to trigger safety warnings. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:35 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.7ce69a413f5217339db39cb1632b9461@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions --------------------------------------------+------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_fail/T8773 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8745 --------------------------------------------+------------------------------ Comment (by Austin Seipp ): In [changeset:"a8a01e742434df11b830ab99af12d9045dfcbc4b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8a01e742434df11b830ab99af12d9045dfcbc4b" Fix #8745 - GND is now -XSafe compatible. As discussed in the ticket, after the landing of #8773, GND is now -XSafe compatible. This fixes the test fallout as well. In particular SafeLang07 was removed following in the steps of SafeLang06, since it no longer failed from GND, but failed due to roles and was thus invalid. The other tests were tweaked to use TemplateHaskell instead of GND in order to trigger safety warnings. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:48:36 -0000 Subject: [GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) In-Reply-To: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> References: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> Message-ID: <057.e34bc2b2da5defa688334e30cd9b252e@haskell.org> #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) ---------------------------------+----------------------------------- Reporter: z9p | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: dlopen dylib so Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+----------------------------------- Comment (by Austin Seipp ): In [changeset:"dc080915597065087b3821b3ded0a621a7e2fae7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dc080915597065087b3821b3ded0a621a7e2fae7" Fix #8770 As usual, Mac OS X is extremely annoying (or the software is, anyway), because not only does it load dynamic libraries with the .dylib extension, but also the .so extension. For whatever reason. At least it's easy to fix. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:49:33 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.2fa392ae8080d7a0fef3c1de038891c2@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:50:25 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.8c6a55fb528f5e484b77b60dd8432a02@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:50:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:50:29 -0000 Subject: [GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) In-Reply-To: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> References: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> Message-ID: <057.dcc533c55af8deb19023bdc462448c80@haskell.org> #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) ---------------------------------+----------------------------------- Reporter: z9p | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: dlopen dylib so Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+----------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:50:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:50:36 -0000 Subject: [GHC] #8735: hpc crashes on platforms using dynamic linking In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.97ad5802b968869cd8a8c9f76cde292e@haskell.org> #8735: hpc crashes on platforms using dynamic linking ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:51:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:51:16 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.9da2040aa196d6767959d61c128538e3@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:52:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:52:09 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.4122b09f2c5ccd23dad47e094587a522@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by thoughtpolice): Thank you! This patch unfortunately doesn't quite work on Linux yet when running 'make install' from a binary distribution. I'll get it going in my tree again to see if I can fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 07:58:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 07:58:38 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.1b157f16215782e4ed48de96b0362f67@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.6.1-rc1 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:03:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:03:28 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. Message-ID: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. --------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: x86_64 | Type of failure: Installing GHC failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ While configuring ghc binary distribution on Solaris I've noted that settings file is not correctly generated: {{{ $ cat settings [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/sfw/bin/gcc"), ("C compiler flags", " "), ("ar command", "/usr/xpg4/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "@ArSupportsAtFile@"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSSolaris2"), ("target arch", "ArchX86"), ("target word size", "4"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} Looks like @ArSupportsAtFile@ is not filled with the right value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:09:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:09:11 -0000 Subject: [GHC] #8788: Remove old comment In-Reply-To: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> References: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> Message-ID: <062.01a7c7e8dcadc038afc39d9f237eb612@haskell.org> #8788: Remove old comment -------------------------------+------------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): doesn't the comment still apply? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:17:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:17:51 -0000 Subject: [GHC] #8788: Remove old comment In-Reply-To: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> References: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> Message-ID: <062.7ffde2a35338361f73d3ae66666ffa65@haskell.org> #8788: Remove old comment -------------------------------+------------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Tarrasch): Did you see my comment in the commit message? I reproduce it here: ''There's no way to reuse the code for say [P, P] and [P, N], since the juxtaposing of code and data when compiling with TABLES_NEXT_TO_CODE.'' Well I guess it still applies if you don't compile with `TABLES_NEXT_TO_CODE`. Here is some more elaboration: If you intend to share the code but have two different tables, you do that by letting the "code-entry-pointer" in the two tables point to the same code. But there's no such "code-entry- pointer" field with `TABLES_NEXT_TO_CODE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:22:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:22:32 -0000 Subject: [GHC] #8788: Remove old comment In-Reply-To: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> References: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> Message-ID: <062.57b7b6e67e40cfb2558b6aef18e21323@haskell.org> #8788: Remove old comment -------------------------------+------------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: closed Priority: lowest | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: The code fragments that the comment is referring to don't have info tables (`stg_ap_stk` and `stg_ap_stk_save`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:51:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:51:22 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.bf8ab0e17acbeb996065f0434beb2691@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser ----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): So your patch re-creates #3756 - is there a way to fix both at the same time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:55:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:55:00 -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.4028f3949d42fc970c710d076db1b051@haskell.org> #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: => thoughtpolice * priority: normal => high * milestone: => 7.10.1 Comment: Looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:56:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:56:53 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.267bd76b78a0ca502b1cc0a9446f97ae@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nomeata): Debian is (slowly, as usual) working towards reproducible builds, and while some Haskell packages satisfy that requirement, others do not ? see this message: https://lists.debian.org/debian- haskell/2014/02/msg00011.html What I find interesting is that `--show-iface` shows now change at all, besides a different interface hash. It would make debugging these issues easier if everything that takes part in the hash calculation was visible in `--show-iface`. Off your head, any idea what else could contribute to a interface change? Built paths and time stamps contribute ''not'' towards the hash, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 08:57:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 08:57:53 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.a1a30c355632039c58fceb33f51b8814@haskell.org> #4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nomeata): Ah, I just see that #8144 was actually fixed after 7.6. I?ll shut up and report back when 7.8 has hit the Debian archives... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:00:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:00:39 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib Message-ID: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, On Solaris 10 and GHC HEAD I get this compilation failure: {{{ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal "inplace/bin/mkdirhier" compiler/stage1/build//. "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. "inplace/bin/ghc-cabal" configure libraries/Cabal/Cabal dist-boot "" --with-ghc="/home/karel/sfw/ghc-7.6.3-new-dist/bin/ghc" --with-ghc- pkg="/home/karel/sfw/ghc-7.6.3-new-dist/bin/ghc-pkg" --package- db=/silence/home/karel/vcs/ghc-src/ghc-sunos5.1x-ranlib- fix/libraries/bootstrapping.conf --disable-library-for-ghci --enable- library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -U__i686 " --configure- option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.18.1.3" --constraint "hpc == 0.6.0.1" --constraint "bin- package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.0" --constraint "transformers == 0.3.0.0" --constraint "terminfo == 0.4.0.0" --with- gcc="/usr/sfw/bin/gcc" --configure-option=--with-cc="/usr/sfw/bin/gcc" --with-ar="/usr/xpg4/bin/ar" --with-ranlib=":" --with- alex="/home/karel/.cabal/bin/alex" --with- happy="/home/karel/.cabal/bin/happy" Configuring Cabal-1.18.1.3... ghc-cabal: Cannot find the program 'ranlib' at ':' or on the path gmake[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 }}} the reason for this failure is that in configure.ac we're using FP_PROG_AR_NEEDS_RANLIB which is defined in aclocal.m4 and uses AC_PROG_RANLIB in its body. The problem is that if ranlib is not found then AC_PROG_RANLIB sets RANLIB variable to `:' which is preferred way of no-op in POSIX shell even slightly more preferable than setting it to true (google for it if you care). Anyway, ghc-cabal tries to execute `:', but this fails since this is shell built-in and not the program/application on the target OS. The fix should be easy, test if RANLIB is set to `:' and set it to true. This works since true is actually a program/application on Solaris 10: {{{ $ which true /usr/bin/true }}} Please note that such failure will happen on all OSes (Unix(-like)) which do not provide ranlib command. Also please note that Solaris 11 is not hit by this issue since it provides ranlib in a form of shell wrapper actually calling just `exit 0' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:00:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:00:51 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib In-Reply-To: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> References: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> Message-ID: <061.f6a3fffa4d89f9dc7edc556da23d1b61@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kgardas): * owner: => kgardas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:07:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:07:06 -0000 Subject: [GHC] #8788: Remove old comment In-Reply-To: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> References: <047.46bb975c5aca033b282201e3f71b4bb7@haskell.org> Message-ID: <062.16950f90527ec865b362c393f4d7af0d@haskell.org> #8788: Remove old comment -------------------------------+------------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: closed Priority: lowest | Milestone: Component: Runtime | Version: 7.6.3 System | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Tarrasch): Whoups, my bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:25:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:25:40 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib In-Reply-To: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> References: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> Message-ID: <061.cc470db60e6463b065fb1d08bcf86697@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by kgardas): * status: new => patch * version: 7.9 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:26:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:26:16 -0000 Subject: [GHC] #8744: "Thread-local storage not supported" for Mac In-Reply-To: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> References: <047.ec1221970b58ef2505c903ba98cb6fc4@haskell.org> Message-ID: <062.2d48df8b5d83dce67fbd66185e29cb0a@haskell.org> #8744: "Thread-local storage not supported" for Mac ----------------------------------------+---------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: These are merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:26:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:26:42 -0000 Subject: [GHC] #8759: Pattern synonyms and TH In-Reply-To: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> References: <047.f30d24adcbc14fc0a0fea67a5d021c0e@haskell.org> Message-ID: <062.3579a80dc8393dcc5cc3b0e0d4b3da43@haskell.org> #8759: Pattern synonyms and TH ---------------------------------------+----------------------------------- Reporter: monoidal | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: th/T8759 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8761 ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:27:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:27:12 -0000 Subject: [GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes In-Reply-To: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> References: <047.d1b09fa1b2f4e10d64fd0fd98e15ebb7@haskell.org> Message-ID: <062.17b9053cac3df64546bf89f466daf575@haskell.org> #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | goldfire Priority: normal | Status: Component: Compiler (Type checker) | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 7.8.1-rc1 Test Case: | Keywords: deriving/should_compile/T8758 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:27:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:27:35 -0000 Subject: [GHC] #8757: Disallow local pattern synonym declarations In-Reply-To: <045.4025838bd3dac3457d42df50984ef416@haskell.org> References: <045.4025838bd3dac3457d42df50984ef416@haskell.org> Message-ID: <060.a9cc66057e5f09e4b190b8d813634203@haskell.org> #8757: Disallow local pattern synonym declarations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: GHC accepts | hour) invalid program | Blocked By: Test Case: | Related Tickets: patsyn/should_fail/local | Blocking: 8749 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:27:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:27:51 -0000 Subject: [GHC] #8749: Pattern synonyms crash GHCi In-Reply-To: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> References: <047.f9f9afc9234eb5051ef30112793358b3@haskell.org> Message-ID: <062.12471ec1baea8d3bdc3a339db95652c8@haskell.org> #8749: Pattern synonyms crash GHCi -------------------------------------+------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8757 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:28:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:28:19 -0000 Subject: [GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? In-Reply-To: <047.7116b27539c649a1f73c0547859a3389@haskell.org> References: <047.7116b27539c649a1f73c0547859a3389@haskell.org> Message-ID: <062.bddc6aa4ddf6089028cbbef9ce99591e@haskell.org> #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: deriving/should_compile/T8631 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:28:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:28:55 -0000 Subject: [GHC] #8706: Kind operators not parsed In-Reply-To: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> References: <047.2693eb213aac077c5a2e8a0d7890650d@haskell.org> Message-ID: <062.d318f192b879e370852a0645f21b544a@haskell.org> #8706: Kind operators not parsed -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:29:12 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.6b09f9174519768da9e62e40ea859e55@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large ---------------------------------------+---------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:29:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:29:35 -0000 Subject: [GHC] #8698: .ctors handling does not work on Windows 64-bit ghci In-Reply-To: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> References: <044.6dfcc266554c4e40f375e52cefa8fdda@haskell.org> Message-ID: <059.ca06e5713ed22148aed03739f76b6691@haskell.org> #8698: .ctors handling does not work on Windows 64-bit ghci -------------------------------+------------------------------------------- Reporter: awson | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Easy (less than 1 hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:29:53 -0000 Subject: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 In-Reply-To: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> References: <048.d0be24b5bb59907c6ef72c048fa707bd@haskell.org> Message-ID: <063.9728c3327969ef00ec1c0f9a3fcf2ef7@haskell.org> #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:32:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:32:55 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.b770ea65e89738d9035e26690bc4d1ce@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Did you test with a non-GNU sed under Solaris? It worked for me under linux. Under Mac OSX I got a (possibly unrelated) failure: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/ dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LC M -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer -gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -no- user-package-db -rtsopts -odir libraries/ba se/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -d ynamic-too -c libraries/base/./Control/Applicative.hs -o libraries/base /dist-install/build/Control/Applicative.o -dyno l ibraries/base/dist-install/build/Control/Applicative.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-apple-darwin): tcIfaceGlobal (local): not found: base:Control.Applicative.$fApplicativeWrappedMonad{v ri} [(0c7, Identifier ?base:Control.Applicative.<*>{v 0c7}?), }}} and under Solaris I got: {{{ gmake[4]: Entering directory `/local/home/maeder/haskell/ghc-7.8.20140130-src/libraries/integer- gmp/gmp/gmpbuild/mpn' /bin/sh ../libtool --tag=CC --mode=compile /opt/csw/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I. . -DOPERATION_`echo fib_table | sed 's/_$//'` -m32 -O2 -pedantic -fomit-frame-pointer -mtune=i386 -march=i386 -c -o f ib_table.lo fib_table.c ../libtool: bad substitution }}} I suspect that gmp can not be compiled without GNU sed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:35:10 -0000 Subject: [GHC] #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable In-Reply-To: <047.811e0564abc56077d47e367aa39c576a@haskell.org> References: <047.811e0564abc56077d47e367aa39c576a@haskell.org> Message-ID: <062.61289ab3037d7682284a4d581c178c07@haskell.org> #8722: powerpc64: error Cannot find a way to declare the thread-local gc variable -------------------------------------+------------------------------------- Reporter: trommler | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:37:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:37:42 -0000 Subject: [GHC] #8365: stage2 build fails on Solaris (SmartOS) In-Reply-To: <049.6c24dae384e0b823465cfdda6a2b9d90@haskell.org> References: <049.6c24dae384e0b823465cfdda6a2b9d90@haskell.org> Message-ID: <064.85404684a00832a333538d98d02144a9@haskell.org> #8365: stage2 build fails on Solaris (SmartOS) ----------------------------------------+--------------------------- Reporter: oddsignals | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Changes (by kgardas): * status: new => closed * resolution: => fixed Comment: I believe this is fixed by b9b94ec82d9125da47c619c69e626120b3e60457 and so should be closed now. If not, please reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:42:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:42:34 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.450603c37666ade3bc448c84c5c0f1a5@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser ----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by slyfox): I think to make it work properly we need to use real code used by ghc with AC_TRY_LINK. Something like that: {{{ AC_TRY_LINK([#include #include "mk/config.h"], [ /* some ghc code using bfd_check_format_matches, bfd_get_symtab_upper_bound, etc */ ]) }}} That way the ./configure linker will try to use the same bfd parts as real code. I'd also like to: - add a manual knob to enable/disable 'bfd' depend - fix memory leak introduced by symbol loading (by unloading them) Does all this sound sane? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 09:53:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 09:53:43 -0000 Subject: [GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling In-Reply-To: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> References: <045.af6493130ade2a702cc9b0745af091cb@haskell.org> Message-ID: <060.91aaf45f334906b16ce9b38f5db19074@haskell.org> #8787: compiler/ghc.mk: restore GhcHcOpts variable handling -------------------------------------+------------------------------------ Reporter: slyfox | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * owner: => thoughtpolice * priority: normal => high * milestone: => 7.10.1 Comment: Interesting, that hasn't worked for quite some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:27:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:27:16 -0000 Subject: [GHC] #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) In-Reply-To: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> References: <042.96be20e6b32e9050bd7ee88ac699de26@haskell.org> Message-ID: <057.7b84ffa82254edc5b74186c215e46447@haskell.org> #8770: ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also) ---------------------------------+----------------------------------- Reporter: z9p | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: dlopen dylib so Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+----------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:27:28 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.ff765cce4a8a9975c2e83330129ae7ea@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:27:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:27:34 -0000 Subject: [GHC] #8735: hpc crashes on platforms using dynamic linking In-Reply-To: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> References: <045.2b2f12687c0b0a1d8cc3388a2a379a4b@haskell.org> Message-ID: <060.9f97ccd03161da3eca8374d6b64d08af@haskell.org> #8735: hpc crashes on platforms using dynamic linking ----------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:27:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:27:50 -0000 Subject: [GHC] #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode In-Reply-To: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> References: <045.dd380d5def70287a92e30e5e9d29b064@haskell.org> Message-ID: <060.6e3ee575b86ca381a841c7e940819a84@haskell.org> #8748: ghc-7.8-rc1/HEAD: --enable-unregisterised fails to build and run with threaded RTS, profiling mode -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8301 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:27:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:27:56 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.af502868f0cc12c92b135203ff8f9276@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions --------------------------------------------+------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_fail/T8773 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8745 --------------------------------------------+------------------------------ Comment (by thoughtpolice): Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:28:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:28:07 -0000 Subject: [GHC] #8773: Require -XIncoherentInstances to write role annotations on class definitions In-Reply-To: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> References: <047.af4ee817fb4417bd7824423cee948a6a@haskell.org> Message-ID: <062.3e8fc9ed6b574550e109bd5a8fb594a5@haskell.org> #8773: Require -XIncoherentInstances to write role annotations on class definitions --------------------------------------------+------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: roles/should_fail/T8773 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8745 --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:28:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:28:13 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.c73ea1488355485cda7118c6feb0d962@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: fixed | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:41:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:41:04 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.7724fbb64a554a37a082b4d05caa6e87@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I wrote a small wiki page with some of my findings, if you work on CSE you might find some of it useful: [[MoreCSE]]. Not many hard insights there, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 10:55:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 10:55:12 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.64acd4e81da7d39c5584cffb5d0c0f80@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser ----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less than a day) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): All sounds good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 11:02:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 11:02:29 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream Message-ID: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I just noticed that unlike other dump flags, `-ddump-splices` dumps to the error stream. I don't think this difference in behaviour is intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 11:30:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 11:30:02 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.89ce92fe6b5bbe95f8f2724502a3a838@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): I doubt it is specifically intended. Do fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 11:44:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 11:44:51 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.e7c340566bc517d65e3347b99b6dcd53@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jstolarek): I looked at the code responsible for this and it seems that this was a concious decision (not sure if correct one). Code is in [[GhcFile(typecheck/TcRnMonad.lhs)]]. There's `dumpTcRn` function which uses `printInfoForUser` to print to `stderr` (`printOutputForUser` would print to `stdout`). `dumpTcRn` is used as a backend for dumping renamer and typechecker traces as well as TH splices. Now I'm not sure if all of this should be printed on stdout or just the TH splices? It seems strange to me that stderr is used as an output for more detailed debugging information. I feel this is not the intent for stderr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 11:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 11:45:32 -0000 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> References: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> Message-ID: <061.a9ced6337cc53d475b0b110ad8cb2300@haskell.org> #2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Reading more code I found this change (a522c3b25eea1fe40edae7052335acce75e8a1c3) introduced in response to #5625, which prevents this eta-expansion to be pedantic about bottoms. The `-fpedantic-bottoms` check was added later. So I guess one could argue that if this flag is off, we should go back to the more liberal eta- expansion. I?ll try that and see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 11:59:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 11:59:29 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.cfc32d725574564e8541f787822b45ae@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by nomeata): Wasn?t there a ticket asking for more structured splice output, i.e. dumping it to a separate file, with precise origin information, basically everything needed to write a tool that reliably replaces the TH code by the splice... Currenlty I only find #5016, which is about getting the dump closer to valid Haskell (also see [http://stackoverflow.com/questions/12169093/can-i -rely-on-template-haskell-expansion-using-ddump-splices-to-always-genera this SE question]). At http://stackoverflow.com/a/15851260/946226 people are surprised that it is dumped to stderr, and not to a file. And there are two tools doing this splace-replacement-thingy already: https://joeyh.name/blog/entry/Template_Haskell_on_impossible_architectures/ and http://hackage.haskell.org/package/zeroth. So it seems that there is demand for improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:06:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:06:03 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.1c3e67f4d9223d44a31ed01900de9ec7@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by simonpj): I probably implemented this, and I don't think stdin/stderr was a conscious choice. Feel free to change it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:34:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:34:07 -0000 Subject: [GHC] #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc (was: Mac OS X does not supply lllvm i.e. opt and llc) In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.00dc0cf58c4d803b6e41274ccf82be39@haskell.org> #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:40:53 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.110853f07115a339a0e1bd5f74eae20a@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by maeder): * priority: normal => lowest * failure: Installing GHC failed => None/Unknown * os: Solaris => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * type: bug => task Comment: this entry looks the same for me also under linux and Mac OSX so it seems to be unused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:48:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:48:26 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.f537fd4127add52e180fb33e698c8942@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by kgardas): Replying to [comment:15 kgardas]: > Got the same issue like nomeata, but on i386-unknown-solaris platform while trying to compile HEAD. Just to let you know: make distclean solved that for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:48:34 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.94d28015024b76cf5bfe6aceb337a06c@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"b626c3d4ce0e66216705ba8355c914dc809e3fe7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b626c3d4ce0e66216705ba8355c914dc809e3fe7" Add comments explaining #8754 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:54:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:54:18 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.46234d58a50126fa987b8d61db18126e@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by kgardas): The MacOSX looks indeed unrelated. I've been hit by it also during the weekend and it was caused probably by some object files lying around from previous and different configured build. See #8374 Solaris issue is interesting, but I'm not able to duplicate it here. So yes, I've tested your patch on both Solaris 11.1 and Solaris 10 and both are able to compile GHC HEAD well. Please keep in mind that I'm minimalistic here, so I configure standard Single Unix Spec. v 3 PATH here (/usr/xpg6/bin:/usr/xpg4/bin:/usr/bin:/usr/ucb....) and I'm running w/o any CSW provided software! My LD_LIBRARY_PATH variable is undefined too. The build is configured with just {{{ $ ./configure }}} and runs fine. Please try to duplicate your issue using my GHC 7.6.3 distro from here: https://app.box.com/s/2nk7ffnr33lpg7b3mxeh -- unset any PATH pointing to /opt/csw. And build with: {{{ $ ./configure $ /opt/csw/bin/gmake }}} BTW: You will probably need to reinstall cabal/alex/happy to be also CSW libraries independent, but this is possible with my bindist provided above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 12:57:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 12:57:11 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.e8c106959b72267e6ec7aed5859519ac@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): So far we are stuck with this because cannot reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 13:38:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 13:38:29 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.1572ba1b5f687d403c1481f12efbd41c@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by maeder): Is this maybe related to reading files? (see https://ghc.haskell.org/trac/ghc/ticket/5013#comment:24) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 13:48:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 13:48:07 -0000 Subject: [GHC] #8797: Buy fresh foods that require preparation like lean proteins, veggies, and fruits. Processed, ready to eat foods have very little nutritional value. Message-ID: <055.33768a49296aa4ba0c7fdf8d17084615@haskell.org> #8797: Buy fresh foods that require preparation like lean proteins, veggies, and fruits. Processed, ready to eat foods have very little nutritional value. ------------------------------------+------------------------------------- Reporter: racquelrodriquez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: GOJI ACTIVES | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If you requirement to turn exploit rid of tumesce fat andantino, you moldiness learn how to set up your daily nutrition and practice so you can course conscionable commence losing tumefy fat. You don't soul to achieve Vast changes in what you do, vindicatory advantage making any weensy changes that leave pay off big example in the later. GOJI ACTIVES You can't start feat rid of swell fat if you don't vantage dynamic what you're doing. Dwarfish changes in your day to day number will hit a big disagreement when it comes to feat rid of swell fat rapid. Same a snowball that gets large when it's trilled land the comic... making undersized changes in your daily fast and lesson function present spring you statesman force that can diffuse you towards your end of a mat viscus. It all starts with your regular nutrition. You are what you eat... so be solon alive of what you're swing into your embody. Interrupt uptake time you're watching TV and instead, grasp out with a someone or know a picnic. Start to bask the trait that's accomplishment on AROUND your matter... and don't put so more pleasure on the food itself. Careful, it's okay to focalise on the pleasures of the substance you eat, but don't cogitate content so untold land that you but can't decide when to occlusive feeding. Instead, use content as what it is: an strength germ for your embody and naught added. Signaling to relish the consort of friends and home or the scenic environment of a holiday. By not swing so more pleasure into the content itself, you can vantage reducing your daily kilocalorie intake which leave service with effort rid of tumesce fat. It's OK to going something on your containerful if you look slaked before you're dressed. You don't hit to act your content and crystallise your shell when you eat, especially when you want to lose whatever tummy fat. Commencement using seemly proportions when you variety your meals. Bed out a rhythmic abstraction of matter and put it on your scale. This way, you mate just how overmuch you're having. Don't go market shopping on an lifeless stomach. That's a instruction for purchase much foods you don't requirement, especially junk foods. Instead, go shopping after you virtuous ate and workplace from a preconditioned list. GOJI ACTIVES Now, the healthy interest is, you don't ever bonk to completely furnish up all your competition foods. You righteous feature to commence reaction them and having them in relief. Pay attending to the delivery filler, especially how umteen servings there are in the substance you're exploit to eat. You deprivation to commencement reducing your daily calorie intake so that getting rid of tumefy fat retributory happens. And the fastest way to do that is by slowly reaction your part sizes. The calorie concept of substance labels can work you win your metric (earn, worsen or hold.) The company of servings you deplete determines the limit of calories you actually eat. Also, be many alert of sugars, metal, and sopping fats... both of which are usually institute in cured foods. Intake too often pure fat, trans fat, cholesterin, or metal may amount your essay of confident diseases suchlike heart disease, soul, or shrill murder somaesthesia. Sugars allow fructose in fruit and disaccharide in dairy products as source as additional sugars much as saccharose (tableland dulcify). Nutritionally, dulcorate is a lyrate carbohydrates that's void calories. http://www.gojiactivesfuncionabr.com/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 14:10:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 14:10:25 -0000 Subject: [GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster In-Reply-To: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> References: <045.70ed8feb506711bb85b526265a1b67a6@haskell.org> Message-ID: <060.db01d21919a39e62557ff15bdc306656@haskell.org> #8766: length [Integer] is twice as slow but length [Int] is 10 times faster --------------------------------------------+------------------------------ Reporter: George | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: T8755 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 14:10:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 14:10:33 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.53626ca04c5bf81723bb8620e86dabf6@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:13:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:13:53 -0000 Subject: [GHC] #5974: Casts, rules, and parametricity In-Reply-To: <046.3b532cdbabf8e03bcada1a28adeccdd5@haskell.org> References: <046.3b532cdbabf8e03bcada1a28adeccdd5@haskell.org> Message-ID: <061.2ffc12e606fa7c4c77192a95c1195dbc@haskell.org> #5974: Casts, rules, and parametricity -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): When matching a lambda `(\x -> g x)` against an expression `(\y -> f y) |> ?`, since [a27b2985] it will push the coercion ? inside the lambda, see `pushCoercionIntoLambda` in source:compiler/coreSyn/CoreSubst.lhs. Similar pushing around could help in other cases where RULES fail to match due to coercions. Also, the ability to mention `coerce` in a RULE (and have it match all kind of coercions) could help with the issues of this tickets. A rule `{-# RULES "foo" forall (f:: y -> z) (xs :: [x]) . map f (coerce xs) = map (coerce f) xs #-}` would possibly help here, but needs more power in the type checker, namely the deconstruction of `Coercible` constraints: {{{ T5974.hs:4:76: Could not coerce from ?y? to ?x? because ?y? and ?x? are different types. arising from a use of ?coerce? from the context (Coercible [x] [y]) bound by the RULE "foo" at T5974.hs:4:11-87 In the first argument of ?map?, namely ?(coerce f)? In the expression: map (coerce f) xs When checking the transformation rule "foo" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:17:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:17:48 -0000 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> References: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> Message-ID: <061.37455362f14fa5ede1c053ec8dba451e@haskell.org> #2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: infoneeded => closed * resolution: => fixed Comment: It seems that not test cases fail with this change, and only one nofib benchmark profits (mandel -1.9%). It would also simplify `CoreArity` (no need for the `ae_bndrs` field). (Or course the scrunitee must not be expensive; I guard this using the `ae_cheap_fn`. If I don't do that, fluid improves allocation by -2.3%, but of course it's wrong. In most cases, though, FloatOut will have ensured that the scrutinee is cheap) I?ll need to run another round of nofib, with an unloaded machine, to ensure that the runtimes are still ok... and here it is {{{ Min -0.1% -1.9% -3.0% -2.9% 0.0% Max +0.0% +0.0% +3.5% +2.2% +3.8% Geometric Mean -0.0% -0.0% -0.4% -0.4% +0.0% }}} Runtime varies a bit, with a slight tendency to an improvement. Guess that is good enough to push. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:18:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:18:27 -0000 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> References: <046.a17f452375c6b159ed122bce785e3f8a@haskell.org> Message-ID: <061.1cb047882fac9c8ba71a4d118d32f026@haskell.org> #2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Joachim Breitner ): In [changeset:"2931d19e90d2366f2ce308d65a36333336ca6059/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2931d19e90d2366f2ce308d65a36333336ca6059" More liberally eta-expand a case-expression at least with -fno-pedantic-bottoms. This fixes #2915, and undoes some of a522c3b, on the grounds that with a flag `-fpedantic-bottoms` around, we can be a bit more liberal when the flag is off.. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:26:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:26:36 -0000 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> References: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> Message-ID: <068.9f9200c5c6f4e8486eb282055bd3a5d4@haskell.org> #3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => patch Comment: Changing `primOpIsCheap` to always True validates, and has no allocation change in nofib. I guess I should be measuring runtime numbers, but for that I?ll need the machine to be unloaded, maybe later today.... Alright, numbers are in: {{{ Min -0.0% -0.0% -7.1% -6.5% -1.8% Max +0.0% +0.0% +2.1% +1.5% +19.8% Geometric Mean -0.0% -0.0% -0.6% -0.5% +0.2% }}} so it seems to be worth it. Not pushing quite yet: Assuming we make the cheapness configurable in `primops.txt.pp`, what primops should not be cheap? To me all of them look cheap (e.g. arithmetic) or are side-effecting (like `copyArray#`, in which case the `primOpIsCheap` information hopefully has no effect. So it seems to me that we do not need to a flag in `primops.txt.pp` just yet; maybe something will show up later. (Marking as for review without a patch because the patch is trivial; it is this question that need to be reviewed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:33:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:33:42 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.3a14a36eefb27a5d20a1a11e7611b3de@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): my second test on OSX went through on a clean tree! (and I could reproduce the crash in the old tree.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:37:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:37:38 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.2bae0e84bc7b2bec8e23588a0f5042b7@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by maeder): Replying to [comment:18 maeder]: > Is this maybe related to reading files? (see https://ghc.haskell.org/trac/ghc/ticket/5013#comment:24) It is not related, because simply re-compiling solved the other issue, whereas this issue can be reproduced if the tree is not cleaned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:44:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:44:17 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.7441e9949da652f5ce2c79602d46438f@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Also building under Solaris went through! (I've got no explanation for the above libtool problem.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 15:46:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 15:46:41 -0000 Subject: [GHC] #8781: check if GNU nm is really needed and if so let configure detect gnm In-Reply-To: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> References: <045.1aa1e8c39f94f72f71f6224837b84ed7@haskell.org> Message-ID: <060.b4c5854b77d7a870d3cd39665c5e1c33@haskell.org> #8781: check if GNU nm is really needed and if so let configure detect gnm ----------------------------------------+----------------------------- Reporter: maeder | Owner: kgardas Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Your nm-patch worked for me, too! {{{ /usr/ccs/bin/nm -bash-3.2$ nm -V nm: Software Generation Utilities (SGU) Solaris-ELF (4.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 16:19:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 16:19:58 -0000 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> References: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> Message-ID: <068.687868a1778ab612667e7ed4fa0a1d52@haskell.org> #3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): For an example where we don't want to duplicate primops, see #5623 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 17:12:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 17:12:25 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.a904e77fc762cf339369d186c7395a8e@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by khyperia): Replying to [comment:6 thoughtpolice]: > Thank you! This patch unfortunately doesn't quite work on Linux yet when running 'make install' from a binary distribution. I'll get it going in my tree again to see if I can fix it. I think I might know the reason. I reference "$1/$2/$$($1_$2_PROG)" in the install rule (in the patch), where I should have referenced "$$($1_$2_INPLACE)". Try switching it and seeing if it works. (I was unsure of which variable to use, so I guessed - apparently wrongly) If that doesn't work... I guess just try various variables for that rule, I'm confused by the mass of dollar signs everywhere and I'm unsure of what variable is what. I'm at work currently and cannot try the change myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 17:40:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 17:40:16 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.974e810fe95231e8c9da8d2f7335c760@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Just to check, we have three givens: {{{ G1: lst ~ n1 : [] G2: lst ~ n0 : n2 G3: n :<=: n2 }}} From the G1,G2 we find `n1 ~ n0`, and from that and G3 we get `n :<=: n1`, which is what we want to prove. Is that the reasoning? Would it be difficult to drop the dependence on `singletons`, or include the code from there that's needed directly into this module? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 17:46:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 17:46:38 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.cc43e33e4d929882455ad7d556108527@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by goldfire): Your text is correct, but your code is not. I believe you meant {{{ G1: lst ~ n1 : [] G2: lst ~ n0 : n2 G3: n :<=: n0 }}} Note the `n0` in the last line. Otherwise, yes, I agree with your comment. I'll try to reduce the case more, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 18:05:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 18:05:20 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.d670c89cf722f92f794cc8bcb9fae3e2@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by goldfire): Here is a version without the `singletons` dependency: {{{ {-# LANGUAGE TypeOperators, DataKinds, PolyKinds, MultiParamTypeClasses, GADTs, ConstraintKinds, TypeFamilies #-} module Bug where data family Sing (a :: k) data Proxy a = Proxy data instance Sing (a :: Maybe k) where SJust :: Sing h -> Sing (Just h) data Dict c where Dict :: c => Dict c -- A less-than-or-equal relation among naturals class a :<=: b sLeq :: Sing n -> Sing n2 -> Dict (n :<=: n2) sLeq = undefined insert_ascending :: (lst ~ Just n1) => Proxy n1 -> Sing n -> Sing lst -> Dict (n :<=: n1) insert_ascending _ n (SJust h) = case sLeq n h of Dict -> Dict }}} Interestingly, when I tried getting rid of the data family, the code started compiling. Perhaps there's a problem with normalisation somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 18:47:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 18:47:00 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.7ac390dccef70821404148ae85be4dac@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by iduhetonas): * status: new => closed * resolution: => fixed Comment: User claims to no longer be experiencing the issue. http://www.haskell.org/pipermail/ghc-devs/2014-February/004051.html Marking as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 18:55:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 18:55:06 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.3ed50120449d5a334ba628654b46630a@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by jstolarek): * status: closed => new * resolution: fixed => Comment: > User claims to no longer be experiencing the issue Wow, wait a sec. I'm not experiencing the issue because I upgraded to new Debian, not because the issue was fixed. I'm reopening the ticket. We should either have a real fix or mark this as wontfix - but the latter is not for me to decide (Herbert?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 20:22:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 20:22:07 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.e06fc76f84ec13c13df54047df004615@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+---------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 8748 ----------------------------------------+---------------------------------- Comment (by simonmar): Looks like this should be fixed by #8748; please re-open if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 20:22:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 20:22:22 -0000 Subject: [GHC] #8301: error BaseReg must be in a register for THREADED_RTS In-Reply-To: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> References: <044.0651fb01dd71f2601e90f46aa455c558@haskell.org> Message-ID: <059.7f23f73d9cf5ee8dbaf889839abb65ea@haskell.org> #8301: error BaseReg must be in a register for THREADED_RTS ----------------------------------------+---------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: 8748 ----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 23:26:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 23:26:28 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.2d6e4fc2a84ff5a75d08a6ee6911978f@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by George): not sure if it helps but I am on 10.9.1 with 4 cpus and 12G of RAM Hardware Overview: Model Name: iMac Model Identifier: iMac11,1 Processor Name: Intel Core i5 Processor Speed: 2.66 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 8 MB Memory: 12 GB Processor Interconnect Speed: 4.8 GT/s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 17 23:26:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Feb 2014 23:26:51 -0000 Subject: [GHC] #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails In-Reply-To: <045.6b8d5402d68421f521d87e4314812585@haskell.org> References: <045.6b8d5402d68421f521d87e4314812585@haskell.org> Message-ID: <060.718a7f68440557ffbd7c93139ee36f1d@haskell.org> #8620: make -j3 build of head on Mac 10.9 with xcode 5 fails ----------------------------------------+---------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by George): * cc: george.colpitts@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 03:48:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 03:48:09 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.b1c905e2247e9983d41f1a94555c4949@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by guest): * status: closed => new * resolution: fixed => Comment: Promoted tuple constructors (e.g. `'(,,)`) still don't parse. This patch to `compiler/parser/Parser.y.pp` fixes it. With this patch, `'` can be used with any `qcon` so the redundant rules have been removed. Using an un-promotable data constructor will give a meaningful error message such as `Data constructor ?(##)? comes from an un-promotable type ?(##)?` instead of a parse error. `'(' varop ')'` was changed to `var` because `'id` is more consistent than {{{'(`id`)}}} and `btype SIMPLEQUOTE varop type` (in `type` and `typedoc`) allows backquoted identifiers as operators. {{{ 1154,1155c1154 < | SIMPLEQUOTE qconid { LL $ HsTyVar $ unLoc $2 } < | SIMPLEQUOTE '(' ')' { LL $ HsTyVar $ getRdrName unitDataCon } --- > | SIMPLEQUOTE qcon { LL $ HsTyVar $ unLoc $2 } 1158,1159c1157 < | SIMPLEQUOTE '(' qconop ')' { LL $ HsTyVar (unLoc $3) } < | SIMPLEQUOTE '(' varop ')' { LL $ HsTyVar (unLoc $3) } --- > | SIMPLEQUOTE var { LL $ HsTyVar $ unLoc $2 } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 08:23:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 08:23:30 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.da013124ebe120d8b6786e8e3bfbc300@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by maeder): Replying to [comment:10 kgardas]: > [...] using my GHC 7.6.3 distro from here: https://app.box.com/s/2nk7ffnr33lpg7b3mxeh [...] I propose to make this binary-dist available via http://www.haskell.org/ghc/download_ghc_7_6_3#binaries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 08:28:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 08:28:12 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.cda54701c8274eb0e0120f659174f213@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: kgardas Type: task | Status: new Priority: lowest | Milestone: Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kgardas): * owner: => kgardas Comment: Fixed by adding omitted FP_PROG_AR_SUPPORTS_ATFILE into the distribution configure.ac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 08:28:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 08:28:42 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.5deb7f4edc4e16df34ce3b664928ebeb@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: kgardas Type: task | Status: patch Priority: lowest | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by kgardas): * status: new => patch * version: 7.6.3 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 08:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 08:46:32 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.c02c11082799720b4101b37002ce8ed8@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------+------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"47f473b0f7ddf21b2cde825166d092cb6e72329d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47f473b0f7ddf21b2cde825166d092cb6e72329d" Use NoGen plan for unboxed-tuple bindings There was a small mixup here, exposed by Trac #8762. Now clarified with better function names and comments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 08:46:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 08:46:32 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.9901fb7b21da538b61a5efce6835b22d@haskell.org> #8739: ($) returning kind # no longer type checks -------------------------------------+------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"5dd1cbbfc0a19e92d7eeff6f328abc7558992fd6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5dd1cbbfc0a19e92d7eeff6f328abc7558992fd6" Allow ($) to return an unlifted type (Trac #8739) Since ($) simply returns its result, via a tail call, it can perfectly well have an unlifted result type; e.g. foo $ True where foo :: Bool -> Int# should be perfectly fine. This used to work in GHC 7.2, but caused a Lint failure. This patch makes it work again (which involved removing code in TcExpr), but fixing the Lint failure meant I had to make ($) into a wired-in Id. Which is not hard to do (in MkId). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 09:17:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 09:17:18 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.fac8410424f5056c33757240142c62f7@haskell.org> #8739: ($) returning kind # no longer type checks -----------------------------------------------+--------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_run/T8739 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by simonpj): * status: infoneeded => merge * testcase: => typecheck/should_run/T8739 Comment: OK I've done this. Since `($)` has a special typing rule anyway, it may as well be very special! Simon PS: Although 7.2 allowed it, if you used `-dcore-lint` it was rejected. I've fixed that too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 09:18:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 09:18:14 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.d47b4271573d45b1ef9885b8458b8b0f@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------------------+------------------------- Reporter: josef | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple typecheck/should_compile/T8762 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T8762 Comment: Fixed, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 09:57:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 09:57:15 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.ded0c721db5714fcf2371e4649a4f876@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Aha. Got it. Thank you. Patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 10:24:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 10:24:34 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes Message-ID: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------------------+------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Hi, Is there any particular reason why there aren't Generic instances for the newtypes under Data.Monoid and Control.Applicative (for example)? I've tried adding them to GHC/Generics.hs and base compiles without problems. Could this addition be considered? Best Regards, Jo?o -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:09:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:09:03 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.2a7edae579545a4925baef3182592288@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by dreixel): `StandaloneDeriving` can be used to get these instances in user code, but I don't see a reason why they shouldn't be provided directly where the type is defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:09:34 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.93bfdb83bf00e292e68fbec5c39f2d9c@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"89d2c048c81020a701ac94d949b4d6f1ced37cfa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89d2c048c81020a701ac94d949b4d6f1ced37cfa" Keep kind-inconsistent Given type equalities (fixes Trac #8705) I was too eager when fixing Trac #8566, and dropped too many equalities on the floor, thereby causing Trac #8705. The fix is easy: delete code. Lots of new comments! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:09:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:09:34 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.b9c9faa53ff6c7b95beee867e226e094@haskell.org> #8566: Given kind equalities are discarded --------------------------------------------+------------------------------ Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8566, T8566a | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"89d2c048c81020a701ac94d949b4d6f1ced37cfa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="89d2c048c81020a701ac94d949b4d6f1ced37cfa" Keep kind-inconsistent Given type equalities (fixes Trac #8705) I was too eager when fixing Trac #8566, and dropped too many equalities on the floor, thereby causing Trac #8705. The fix is easy: delete code. Lots of new comments! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:09:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:09:58 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.75493286bcec49d059eec878448fbf0b@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8705 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * status: new => merge * testcase: => polykinds/T8705 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:15:36 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.02a1f3f0b0abb3a17c2ea0640135c264@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Comment (by simonpj): I have not reviewed in detail, but what you say sounds good. Would someone like to update the user-manual documentation (if necessary), validate, and commit? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:18:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:18:03 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.0b00e40df30d16e6c8a0494a20e47b4d@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by simonpj): * cc: ekmett@? (added) Comment: I guess this is a library issue. Edward and the core library committee, over to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:37:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:37:57 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.ce0a363734805da5f2833507d2639a45@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jcristovao): ```StandaloneDeriving``` can be used Yes, of course, but there is always the (increased) risk of two libraries using it, and thus having ```Duplicate instance declarations```. I would say its safer to include this in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 11:54:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 11:54:22 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.b1e5240c30220ce63299363f840569d3@haskell.org> #3924: Strictness analyser missing useful strictness -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This looks like it can be solved by the new callartiy analysis. It does now, because * all the functions are top-level functions, and callartiy analysis now also looks at top-level functions, and * they are mutually recursive, which the callarity analysis does handle now. Now we get these signatures: {{{ $wf3 :: Int# -> Int# -> Int# -> Int# $wf4 :: Int# -> Int# -> Int# -> Int# -> Int# }}} (and f2 has disappeared, by inlining I supposed). Code is currently validating and will hit master soon after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 12:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 12:16:46 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.bffd41b67dfedfdce2ccef0a7566dd6b@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"642bba349fda1508aa136f7169c0ba63fb00a6f9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="642bba349fda1508aa136f7169c0ba63fb00a6f9" Revert "Add comments explaining #8754" This reverts commit b626c3d4ce0e66216705ba8355c914dc809e3fe7. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 12:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 12:16:46 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.997a230be2922d7a8261a7842c649cf0@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"e789a4f51b6205160a696e3e6e13ecefb5ae16f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e789a4f51b6205160a696e3e6e13ecefb5ae16f7" Revert "Fix #8754 in a round-about way." This reverts commit 5023c91780e90947680fe0640f7564a4f6448bea. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 12:26:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 12:26:49 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.bf9910115b03ebf2e1132677dc29596f@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by hvr): * status: closed => new * resolution: fixed => Comment: re-opened (see also [http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/3761 ghc-dev post]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 15:35:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 15:35:23 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.57852e4384494da2d7535bd7c2b056ff@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ekmett): I personally have no objection and think it'd be a good idea. The `Generic` and `Generic1` instances clearly belong with their definitions. They also deserve `Typeable` and `Data`. Forcing the user to supply them risks conflicting orphans, making Haskell libraries less composable and there is no real data hiding argument to be made about transparent newtypes from base. I'll definitely put it to the committee and see what they think. In particular, while these 4 seem pretty obvious to me, there are some data types in there that could really use a few other instances as well. e.g. the fact that there is no `instance Num a => Num (Sum a)` or `instance Num a => Num (Product a)` is something I hear fairly regular complaints about in #haskell and none of the various reimplementations on hackage do anything but the obvious. Those start to speak to changing the suggested usage of these monoidal wrappers from something you 'put on long enough to foldMap' to something your data might live in long-term, but looking around that is what folks are actually doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 16:12:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 16:12:22 -0000 Subject: [GHC] #8798: Missing symbols with -fprof-auto-calls Message-ID: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> #8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 16:33:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 16:33:32 -0000 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> References: <053.0019c225828c125ef2fe245d50116a1f@haskell.org> Message-ID: <068.75335669ead3bf4777af684a67d1be0b@haskell.org> #3034: divInt# floated into a position which leads to low arity --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): And we don't have a reproducible test case. So let's just park this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:13:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:13:02 -0000 Subject: [GHC] #8798: Missing symbols with -fprof-auto-calls In-Reply-To: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> References: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> Message-ID: <059.ab6a977b2bef33b8c8ed49b363568486@haskell.org> #8798: Missing symbols with -fprof-auto-calls -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by snoyberg): * cc: michael@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:22:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:22:34 -0000 Subject: [GHC] #8799: Orientation of given `Coercible` constraints Message-ID: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> #8799: Orientation of given `Coercible` constraints -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8555 | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :m + GHC.Exts Prelude GHC.Exts> let f :: Coercible a b => b -> a ; f = coerce :3:40: Could not coerce from ?b? to ?a? because ?b? and ?a? are different types. arising from a use of ?coerce? from the context (Coercible a b) bound by the type signature for f :: Coercible a b => b -> a at :3:10-32 In the expression: coerce In an equation for ?f?: f = coerce }}} Something better could be done here (but its not clear what exactly, and to what general extend). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:22:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:22:52 -0000 Subject: [GHC] #8555: Simplify given `Coercible` constraints In-Reply-To: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> References: <046.a1497cad7416e0b2528d2d39ab4215f8@haskell.org> Message-ID: <061.9d47389ec3b9c0b80b81ca90a688a2f8@haskell.org> #8555: Simplify given `Coercible` constraints ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8503 | #8555 ----------------------------------------------+---------------------------- Changes (by nomeata): * related: #8503 => #8503 #8555 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:32:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:32:05 -0000 Subject: [GHC] #8798: Missing symbols with -fprof-auto-calls In-Reply-To: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> References: <044.ec0f35676741d6c60bda2b0c22aed413@haskell.org> Message-ID: <059.a1b07a47d64394ddde6a0f9424ca48aa@haskell.org> #8798: Missing symbols with -fprof-auto-calls -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): I can reproduce this in 7.8. The error from the Linux linker is a little more informative: {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... /home/rwbarton/.cabal/lib/x86_64-linux-ghc-7.8.0.20140204/xml- conduit-1.1.0.9/libHSxml-conduit-1.1.0.9_p.a(Parse.p_o): In function `c1noU_info': /tmp/ghc14255_0/ghc14255_28.p_o:(.text+0x8ca17): undefined reference to `attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc' /home/rwbarton/.cabal/lib/x86_64-linux-ghc-7.8.0.20140204/xml- conduit-1.1.0.9/libHSxml-conduit-1.1.0.9_p.a(Parse.p_o): In function `c1oKY_info': /tmp/ghc14255_0/ghc14255_28.p_o:(.text+0x9619f): undefined reference to `attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc' collect2: error: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:39:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:39: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.6bd468470530a380c34bef6467af0869@haskell.org> #8799: Orientation of given `Coercible` constraints --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8555 --------------------------------------------+------------------------------ Comment (by goldfire): There is similar behavior when trying to test transitivity. I don't have any suggestions of how to fix this without a whole lot of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:44:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:44:10 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.8f9fc0e74b443671f163403b6e746006@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): @simonpj: you might want to take a look at these patches before they land, since they make a lot of changes in coreSyn and the simplifier. Start here, and in particular look at `SourceNote` for high-level comments: https://github.com/scpmw/ghc/commit/d233ea4da0a5725d4d29a3fb68b9b8f7c9bc6d32 #diff-8b5b79c6cb1af2b387fa2d814cd0d3f6R1638 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 17:49:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 17:49:45 -0000 Subject: [GHC] #8799: Orientation of given `Coercible` constraints In-Reply-To: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> References: <046.7264a6ebb9a317e8eef7a9bcefad9be5@haskell.org> Message-ID: <061.16a492012238f17e694dd4f275ac55ba@haskell.org> #8799: Orientation of given `Coercible` constraints --------------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8555 --------------------------------------------+------------------------------ Comment (by rwbarton): FWIW this works (with !ScopedTypeVariables): {{{ let f :: forall a b. Coercible a b => b -> a; f = coerce (id :: a -> a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 18:57:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 18:57:45 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.afc4b20c74056c347e91c54ab7a2e351@haskell.org> #3924: Strictness analyser missing useful strictness -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner ): In [changeset:"d3c579c75ffec4346a043582d89205998790145e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d3c579c75ffec4346a043582d89205998790145e" Call arity testcase for #3924 nice numbers coming from these micro-benchmarks. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 19:04:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 19:04:55 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.357219582dddd51511305af9ea9b5b13@haskell.org> #3924: Strictness analyser missing useful strictness -----------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: callarity/perf/T3924 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Changes (by nomeata): * status: new => closed * testcase: => callarity/perf/T3924 * resolution: => fixed Comment: Allright, pushed (mostly 2ab00bf and f347bfe) and testcase added. This concludes my internship at MSRC; any further bugs introduced by me can no longer be blamed on ?a microsoft employee?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 20:17:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 20:17:12 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.1fbc3fd12c75452792365787808f3cc4@haskell.org> #3924: Strictness analyser missing useful strictness -----------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: callarity/perf/T3924 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by simonpj): Terrific. What were the "nice numbers"? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 18 21:10:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Feb 2014 21:10:05 -0000 Subject: [GHC] #3924: Strictness analyser missing useful strictness In-Reply-To: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> References: <046.d0f8141a932679328e1597ad92a19bcb@haskell.org> Message-ID: <061.77ebaf5f9d64fc77902444112f96823b@haskell.org> #3924: Strictness analyser missing useful strictness -----------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: callarity/perf/T3924 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by nomeata): > Terrific. What were the "nice numbers"? I was referring to the effect of call-arity to the (very artificial) code of this ticket: Allocation went from 22326544 to 51480. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 05:41:55 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 05:41:55 -0000 Subject: [GHC] #8800: hpc dyld issue Message-ID: <047.f1c18449ff802825323fddb5de3ca889@haskell.org> #8800: hpc dyld issue ----------------------------------+--------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ $ hpc dyld: Library not loaded: @rpath/libHShpc-0.6.0.1-ghc7.8.20140130.dylib Referenced from: /usr/local/bin/hpc Reason: image not found zsh: trace trap hpc }}} on OSX Mavericks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 06:54:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 06:54:56 -0000 Subject: [GHC] #8800: hpc dyld issue In-Reply-To: <047.f1c18449ff802825323fddb5de3ca889@haskell.org> References: <047.f1c18449ff802825323fddb5de3ca889@haskell.org> Message-ID: <062.7242947e582dd7a4270e936171b438dc@haskell.org> #8800: hpc dyld issue ----------------------------------+---------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by carter): * priority: normal => highest * milestone: => 7.8.1 Comment: i have it on my own build of RC1 too. I'll try testing 7.8 branch head sometime tomorrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 08:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 08:41:45 -0000 Subject: [GHC] #8800: hpc dyld issue In-Reply-To: <047.f1c18449ff802825323fddb5de3ca889@haskell.org> References: <047.f1c18449ff802825323fddb5de3ca889@haskell.org> Message-ID: <062.e0217938efd1166f0a7c62f995bb48f7@haskell.org> #8800: hpc dyld issue ----------------------------------+---------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Code Coverage | Version: 7.8.1-rc1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #8735 which is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 10:19:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 10:19:59 -0000 Subject: [GHC] #8801: Exclude extralibs from sdist Message-ID: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> #8801: Exclude extralibs from sdist ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Am Mittwoch, den 19.02.2014, 11:13 +0100 schrieb Herbert Valerio Riedel: On 2014-02-18 at 23:22:13 +0100, Joachim Breitner wrote: > > Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox: > >> It seems to me that the stm library that is supposed to be built into > >> ghc-7.8.1 is missing. The deb provides and conflicts with > >> libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde. > > > > this seems to be the result of a possible inadvertent change in the GHC > > source tarball creation: stm had been a "extra" lib already in 7.6 and > > before, but was not part of the tarball. > > > > Herbert or Austin, is the sdist code not doing the right thing here? > > Afaics, 'stm' is only used as an "extra" lib by testsuite (and only for > one test-case) and nofib; therefore I don't think the GHC source tarball > is supposed to contain 'stm'... (This is so that he who fixes this has a bug to close, which is always rewarding.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 12:31:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 12:31:07 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.bd4e2e3987e38396a209c2a4539f3dda@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.4.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by bjp): * cc: bjp@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 12:51:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 12:51:48 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters Message-ID: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I've just run into severe usability issue with the `process` library. It turns out that it performs quoting and escaping of command line parameters. The result is that it is impossible to run many shell commands that contain "unsafe" characters: {{{ diff <(echo $ENV_FOO) <(echo $ENV_BAR) awk 'NR<=10' Foo.txt }}} because they are turned into some nonsense. The culprit is `translate` function in libraries/process/System/Process/Internal.hs. I'm not fixing this myself as I assume there was some motivation behind escaping and quoting. I'm assigning high priority as it makes impossible to create shell processes correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 13:08:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 13:08:15 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.6debe197942da9eb2e7682e6502f2ce2@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): I guess you talking about `runCommand` (which goes via the shell), and not `runProcess` (which executes programs directly)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 13:14:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 13:14:39 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.2aa4b9887f5092918fcc2e8c94c2b377@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by jstolarek): I am thinking about `createProcess`. Both `runCommand` and `runProcess` are planned to be deprecated (haddock documentation already lists them in section "Old deprecated functions"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 14:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 14:01:56 -0000 Subject: [GHC] #8705: Type inference regression with local dictionaries In-Reply-To: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> References: <047.76aef3f96e6b74381b08965fc4fda2bf@haskell.org> Message-ID: <062.b733bd348dc3ceb33dcb50f7fa51da59@haskell.org> #8705: Type inference regression with local dictionaries --------------------------------------------+------------------------------ Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: polykinds/T8705 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 14:02:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 14:02:12 -0000 Subject: [GHC] #8739: ($) returning kind # no longer type checks In-Reply-To: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> References: <051.9a9af979b7e4a58bec1c60436784d13c@haskell.org> Message-ID: <066.235e7c0c6cbc89905bc5a4f912e26576@haskell.org> #8739: ($) returning kind # no longer type checks -----------------------------------------------+--------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: typecheck/should_run/T8739 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: -----------------------------------------------+--------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 14:02:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 14:02:28 -0000 Subject: [GHC] #8762: Panic involving unboxed tuples and phantom types In-Reply-To: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> References: <044.e26873e2676e0aa4a77709b5ae5de455@haskell.org> Message-ID: <059.008cc9e0d4a6629a37bf95dba2464000@haskell.org> #8762: Panic involving unboxed tuples and phantom types -------------------------------------------------+------------------------- Reporter: josef | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Test Case: | Architecture: typecheck/should_compile/T8762 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 16:47:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 16:47:12 -0000 Subject: [GHC] #8803: ghc panic ((!!): index too large) when building some packages Message-ID: <047.4bae8755970d1749d96cdb8395f084ad@haskell.org> #8803: ghc panic ((!!): index too large) when building some packages ----------------------------------+--------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm not 100% sure what the cause of this is, because I can't get a reproducible test case. If I try to build `postgresql-simple`, this is the output from cabal (with `-v3`): https://gist.github.com/anonymous/bda9095cee1eda5640c0 Wondered whether it was related to hs-boot files, but I cannot reproduce the error with the basic example from http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/separate- compilation.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 17:04:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 17:04:34 -0000 Subject: [GHC] #8803: ghc panic ((!!): index too large) when building some packages In-Reply-To: <047.4bae8755970d1749d96cdb8395f084ad@haskell.org> References: <047.4bae8755970d1749d96cdb8395f084ad@haskell.org> Message-ID: <062.e0e93ff67a602fc74653a903cf1361f8@haskell.org> #8803: ghc panic ((!!): index too large) when building some packages ---------------------------------------+---------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => duplicate Comment: Duplicate of #8743 which is fixed - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 20:03:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 20:03:28 -0000 Subject: [GHC] #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread Message-ID: <045.61996263d69494df356fa9ae5390b99a@haskell.org> #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread --------------------------+------------------------------------------------ Reporter: bholst | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Runtime System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ GHC's runtime system throws a BlockedIndefinatelyOnMVar exception when the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future. This would be the correct behaviour if there were no weak references. The runtime system even throws the Exception when another thread still has a weak reference to the MVar. Consider the following example: {{{ import Control.Concurrent import System.Mem.Weak import Data.Maybe import Control.Monad main = do m <- newEmptyMVar w <- mkWeakMVar m (return ()) forkIO $ do threadDelay 1000000 n <- deRefWeak w when (isJust n) $ putMVar (fromJust n) () takeMVar m }}} At the time of ''takeMVar'' the forked thread has a weak reference to the MVar and it will put a value in it. However, the runtime system throws the Exception: {{{ % ghc BlockingOnMVar.hs -threaded Linking BlockingOnMVar ... % ./BlockingOnMVar +RTS -N2 BlockingOnMVar: thread blocked indefinitely in an MVar operation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 20:33:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 20:33:59 -0000 Subject: [GHC] #8786: libraries/primitive build failure on Solaris 10 In-Reply-To: <046.935806b919fa984f3495fcf0b192593a@haskell.org> References: <046.935806b919fa984f3495fcf0b192593a@haskell.org> Message-ID: <061.084774b8015e3fbd3e8e6c6ec19e0fa3@haskell.org> #8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc1 (other) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kgardas): * status: new => patch Comment: My patch was merged upstream. I'm switching state to patch to show that it's possible now to merge it from upstream to GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:00:25 -0000 Subject: [GHC] #7689: Primitive bitwise operations on Int# In-Reply-To: <048.0257387ddf336d499fc3f21c5d9d0b33@haskell.org> References: <048.0257387ddf336d499fc3f21c5d9d0b33@haskell.org> Message-ID: <063.3ac2f9c33330393dc21e26aed81c865a@haskell.org> #7689: Primitive bitwise operations on Int# ------------------------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T7689.hs | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0fc4fb5477d3ca22a8b6894db5b1112b9badfdc4/base"]: {{{ #!CommitTicketReference repository="base" revision="0fc4fb5477d3ca22a8b6894db5b1112b9badfdc4" Use new bitwise Int# primops in Data.Bits (re #8791) The new primops (see also #7689) allow to optimize `instance Bits Int` by allowing to operate directly on Int# instead of having to convert to Word# and back to Int# again. Authored-by: Chris Dueck Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:00:25 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations for Int# in Data.Bits In-Reply-To: <042.dafef0a3988131827ed64c838619782e@haskell.org> References: <042.dafef0a3988131827ed64c838619782e@haskell.org> Message-ID: <057.afa04f9a500f2da77b9a02f75eea9a1f@haskell.org> #8791: Use new primitive bitwise operations for Int# in Data.Bits -------------------------------------+------------------------------------ Reporter: cdk | Owner: cdk Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 7689 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"0fc4fb5477d3ca22a8b6894db5b1112b9badfdc4/base"]: {{{ #!CommitTicketReference repository="base" revision="0fc4fb5477d3ca22a8b6894db5b1112b9badfdc4" Use new bitwise Int# primops in Data.Bits (re #8791) The new primops (see also #7689) allow to optimize `instance Bits Int` by allowing to operate directly on Int# instead of having to convert to Word# and back to Int# again. Authored-by: Chris Dueck Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:02:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:02:01 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations for Int# in Data.Bits In-Reply-To: <042.dafef0a3988131827ed64c838619782e@haskell.org> References: <042.dafef0a3988131827ed64c838619782e@haskell.org> Message-ID: <057.b553552e2dc0f6c26e46309c5bbfe9b4@haskell.org> #8791: Use new primitive bitwise operations for Int# in Data.Bits -------------------------------+------------------------------------------- Reporter: cdk | Owner: cdk Type: feature | Status: merge request | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7689 Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * status: patch => merge * difficulty: Unknown => Easy (less than 1 hour) * type: task => feature request * related: 7689 => #7689 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:34:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:34:26 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.3d9b7a3272a1e809b8b66d42ba4f2070@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: kgardas Type: task | Status: patch Priority: lowest | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"43c314c730d205a3ec8ef5d54e5bf72a7900f01d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="43c314c730d205a3ec8ef5d54e5bf72a7900f01d" add omitted FP_PROG_AR_SUPPORTS_ATFILE into the distribution configure.ac (fixes #8794) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:34:27 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib In-Reply-To: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> References: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> Message-ID: <061.342a0ff29c91c9666b98c5ec8a188079@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5c6ced556a989e7fccfa2d4adc6f6bbe538a8e6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c6ced556a989e7fccfa2d4adc6f6bbe538a8e6c" fix build failure on Solaris 10 due to RANLIB being set to ':' by configure (#8795) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:34:27 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.15d9159db5bf834d552d7bd3aa4d638e@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Comment (by Austin Seipp ): In [changeset:"e638acb6a825559fbd93bdaf8ae2704535c157f1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e638acb6a825559fbd93bdaf8ae2704535c157f1" fix sed expression in build dependencies rules to work well with non-GNU sed (fixes #8764) The patch is provided by Christian Maeder Signed-off-by: Karel Gardas Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:34:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:34:52 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib In-Reply-To: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> References: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> Message-ID: <061.fa21a436dd2db51a5607966b6cf91b15@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:35:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:35:00 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.a731fe1443302597ffaa609d6b7466f0@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: kgardas Type: task | Status: merge Priority: lowest | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:35:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:35:12 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.eecd24f8203d506a219d2b029e3cdcd0@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:35:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:35:47 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode In-Reply-To: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> References: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> Message-ID: <060.d64fd5ab17e5bc879f9302d3e467b56e@haskell.org> #8719: clarify prefetch release notes + remove some deadcode -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => merge Comment: Merged in HEAD. The 'dead code' is not actually dead code, because by removing it `./validate` gets angry due to incomplete pattern matches. I've cherry picked the documentation patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:40:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:40:38 -0000 Subject: [GHC] #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.a2a6b5285deb08c59fbbc15b0ad09597@haskell.org> #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2b34947b60069e51abfcada9c45a6d7b590f5a2b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2b34947b60069e51abfcada9c45a6d7b590f5a2b" Clear up docs regarding LLVM backend (#8792) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:40:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:40:52 -0000 Subject: [GHC] #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.76be70dd7d0d1c7c7320e87efcae57b4@haskell.org> #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 22:43:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 22:43:16 -0000 Subject: [GHC] #8786: libraries/primitive build failure on Solaris 10 In-Reply-To: <046.935806b919fa984f3495fcf0b192593a@haskell.org> References: <046.935806b919fa984f3495fcf0b192593a@haskell.org> Message-ID: <061.d75738efb8a119813ca58e3e8d3f5523@haskell.org> #8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc1 (other) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 23:35:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 23:35:25 -0000 Subject: [GHC] #8805: QuasiQuote should imply -dynamic-too, too Message-ID: <044.384db18e87dddbf21a695e0e04d391b3@haskell.org> #8805: QuasiQuote should imply -dynamic-too, too ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- (On applicable hardware and OSes. And suppose no -dynamic flag is given.) QuasiQuote does not implicitly trigger -dynamic-too. (TemplateHaskell already does, which is good.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 19 23:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Feb 2014 23:42:33 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.d66cad3db94d045ad408dc77f16da322@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): I see. But the `translate` function is only used on Windows, for reasons explained in `-- Escaping commands for shells` in System.Process.Internals ? is your bug report about Windows? Can you maybe give a concrete example of what should work and does not, so that it can be turned into a testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 00:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 00:06:41 -0000 Subject: [GHC] #8806: Invalid constraints should fail to type check Message-ID: <044.7cbae69d1cf5a8ae601c94fd3e091cbb@haskell.org> #8806: Invalid constraints should fail to type check -------------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- With ghc-7.6.3 the following code: {{{ f :: Int => Int f x = x + 1 }}} should fail to type check, but instead compiles and runs as if it was: {{{ f :: Int -> Int f x = x + 1 }}} With 7.8rc1 and git HEAD this results in an error: {{{ Expected a constraint, but ?Int? has kind ?*? In the type signature for ?f?: f :: Int => Int }}} We should add a "shouldn't type check" test to avoid the possibilty of a regression. Also: {{{ g :: (Int => Show a) => Int g = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 04:08:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 04:08:26 -0000 Subject: [GHC] #8807: Variable constraints not handled properly in TH Message-ID: <047.bf644d2dcafed70da75aadeef4a4e28b@haskell.org> #8807: Variable constraints not handled properly in TH ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile {{{ {-# LANGUAGE TemplateHaskell, ConstraintKinds #-} module Scratch where import Data.Proxy foo :: $( [t| a b => Proxy a -> b -> b |] ) foo = undefined }}} I get {{{ Illegal type constructor or class name: ?a? When splicing a TH type: forall a_0 b_1 . a_0 b_1 => Data.Proxy.Proxy a_0 -> b_1 -> b_1 In the splice: $([t| a b => Proxy a -> b -> b |]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 05:40:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 05:40:53 -0000 Subject: [GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments Message-ID: <044.1b0554fe8d821cf54101cba5a613a396@haskell.org> #8808: ImpredicativeTypes type checking fails depending on syntax of arguments -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- g1 and g2 below type check, but g1', g2', and g2'' don't even though the types are exactly the same. {{{ {-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-} module Test where f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char]) f1 (Just g) = Just (g [3], g "hello") f1 Nothing = Nothing f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char]) f2 [g] = Just (g [3], g "hello") f2 [] = Nothing g1 = (f1 . Just) reverse g1' = f1 (Just reverse) g2 = f2 [reverse] g2' = f2 ((:[]) reverse) g2'' = f2 (reverse : []) }}} Compiling it with HEAD gives these errors: {{{ [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:12:16: Couldn't match expected type ?forall a. [a] -> [a]? with actual type ?[a2] -> [a2]? In the first argument of ?Just?, namely ?reverse? In the first argument of ?f1?, namely ?(Just reverse)? test.hs:15:17: Couldn't match expected type ?forall a. [a] -> [a]? with actual type ?[a0] -> [a0]? In the first argument of ?: []?, namely ?reverse? In the first argument of ?f2?, namely ?((: []) reverse)? test.hs:16:12: Couldn't match expected type ?forall a. [a] -> [a]? with actual type ?[a1] -> [a1]? In the first argument of ?(:)?, namely ?reverse? In the first argument of ?f2?, namely ?(reverse : [])? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 06:21:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 06:21:35 -0000 Subject: [GHC] #8809: Prettier error messages? Message-ID: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> #8809: Prettier error messages? ------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `clang` has very nice-looking error messages. {{{ #!html 
pretty.c:6:7: warning: incompatible pointer to integer conversion passing
 'char [14]' to parameter of type 'int' [-Wint-conversion]
   foo("Hello, world!");
       ^~~~~~~~~~~~~~~
 pretty.c:1:14: note: passing argument to
 parameter 'i' here
 void foo(int i) {
              ^
 1 warning generated.
}}} `ghc`'s error messages are not so good. {{{ #!html 
ugly.hs:7:18:
     Couldn't match expected type ‘()’ with actual type
 ‘[Char]’
     In the first argument of ‘f’, namely ‘"Hello,
 world!"’
     In the second argument of ‘($)’, namely ‘f "Hello,
 world!"’
     In the expression: print $ f "Hello, world!"
}}} In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text. Consider all three applied to error messages: {{{ #!html 
ugly.hs:7:18: error: Argument
 to 'f' is type '[Char]' but expected 'Int'
 main = print $ f "Hello, world!"
                  ^~~~~~~~~~~~~~~

 ugly.hs:3:1: note: type of 'f' is given here:
 f :: () -> IO ()
      ^~
}}} or {{{ #!html 
ugly.hs: note: type of 'f' is inferred:
 f :: forall m. Monad m => () -> m ()
                           ^~
}}} In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above: {{{ ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int' main = print $ f "Hello, world!" ^~~~~~~~~~~~~~~ ugly.hs:3:1: note: type of 'f' is given here: f :: () -> IO () ^~ }}} In my opinion this is much easier to visually process than GHC's current messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 07:13:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 07:13:00 -0000 Subject: [GHC] #8805: QuasiQuote should imply -dynamic-too, too In-Reply-To: <044.384db18e87dddbf21a695e0e04d391b3@haskell.org> References: <044.384db18e87dddbf21a695e0e04d391b3@haskell.org> Message-ID: <059.d67f70aea0e56cf85c2d657279d92886@haskell.org> #8805: QuasiQuote should imply -dynamic-too, too -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => merge * milestone: => 7.8.1 Comment: Pre-emptively fixed in e75ebc487b68a07bd632b51df62d9047c559f19f - thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 07:18:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 07:18:33 -0000 Subject: [GHC] #8801: Exclude extralibs from sdist In-Reply-To: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> References: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> Message-ID: <061.5c2b1d4864173183b16aee152338a668@haskell.org> #8801: Exclude extralibs from sdist -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"f99a0321a8cf0507924a0d30b6b7b586d7855129/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f99a0321a8cf0507924a0d30b6b7b586d7855129" Fix #8801: exclude extra packages from the sdist. This is special cased a little since it's cleaner, and we don't necessarily want to remove nofib anyway - just the extra packages. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 07:18:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 07:18:43 -0000 Subject: [GHC] #8801: Exclude extralibs from sdist In-Reply-To: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> References: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> Message-ID: <061.f210f1c9af8b7121c07daa63c23bd234@haskell.org> #8801: Exclude extralibs from sdist -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 08:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 08:03:17 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' Message-ID: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' ----------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Found by clang when building unreg compiler (but should affect all builds): {{{ rts_dist_HC rts/dist/build/RetainerProfile.p_o rts/RetainerProfile.c:1779:5: error: implicit declaration of function 'markStableTables' is invalid in C99 [-Werror,-Wimplicit-function-declaration] markStableTables(retainRoot, NULL); ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 08:11:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 08:11:57 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.4f047d6fa809b781ca498d07e181d0f2@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by jstolarek): * os: Unknown/Multiple => Linux Comment: Replying to [comment:3 nomeata]: > But the `translate` function is only used on Windows No: {{{ translate :: String -> String #if mingw32_HOST_OS translate xs = '"' : snd (foldr escape (True,"\"") xs) where escape '"' (_, str) = (True, '\\' : '"' : str) escape '\\' (True, str) = (True, '\\' : '\\' : str) escape '\\' (False, str) = (False, '\\' : str) escape c (_, str) = (False, c : str) -- See long comment above for what this function is trying to do. -- -- The Bool passed back along the string is True iff the -- rest of the string is a sequence of backslashes followed by -- a double quote. #else translate "" = "''" translate str -- goodChar is a pessimistic predicate, such that if an argument is -- non-empty and only contains goodChars, then there is no need to -- do any quoting or escaping | all goodChar str = str | otherwise = '\'' : foldr escape "'" str where escape '\'' = showString "'\\''" escape c = showChar c goodChar c = isAlphaNum c || c `elem` "-_.,/" #endif }}} > is your bug report about Windows No, it's about Linux (does Windows even have awk?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 08:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 08:12:09 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' In-Reply-To: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> References: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> Message-ID: <060.90e9d09cd059d2b72c29a48917bfb98e@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by slyfox): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 08:13:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 08:13:56 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.6363e64d20114e9f8c96fb25b99950e1@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by jstolarek): The example I just attached fails because parameters to `diff` are surrounded with `'` - see comment in the file. This is exactly what `translate` function does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 09:14:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 09:14:32 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.13df78592d9028a4b5a12420224249ea@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d3af9807ca8a1db0bc9298ea50895ee9df55edb7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d3af9807ca8a1db0bc9298ea50895ee9df55edb7" Really fix #5682 (parsing of promoted datacons) Patch submitted by an anonymous friend on the bug tracker. This also fixes TH_RichKinds2 which had a slight message output wibble (it uses the qualified name of the promoted datacon) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 09:15:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 09:15:02 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.0cf40222ffe23bd9a7803502e0670ef2@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge Comment: Thanks, merged! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 09:16:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 09:16:31 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' In-Reply-To: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> References: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> Message-ID: <060.a4a4232c75eb054bb82b3eeaf5729027@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 09:36:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 09:36:34 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' In-Reply-To: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> References: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> Message-ID: <060.e58f5ff2602e3c67fb8a9441fe2b7a2c@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"925b0a499dba8a891af06f1bd3f5caf063682b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="925b0a499dba8a891af06f1bd3f5caf063682b0b" RetainerProfile.c: include missing header (#8810) Found by clang: rts_dist_HC rts/dist/build/RetainerProfile.p_o rts/RetainerProfile.c:1779:5: error: implicit declaration of function 'markStableTables' is invalid in C99 [-Werror,-Wimplicit-function-declaration] markStableTables(retainRoot, NULL); Signed-off-by: Sergei Trofimovich Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 09:37:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 09:37:04 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' In-Reply-To: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> References: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> Message-ID: <060.73f73fa9dbde6fb2a6ce4edd38aef120@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 10:30:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 10:30:12 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.27eef8dc0c170864d670368edb4e3c83@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Well, if you check where `translate` is being used: It is only used on Windows (and on Linux when ''showing'' the command). In your example you are using `proc`, where the main feature is precisely that it is ''not'' being passed through the shell. This is important: With `proc` it is safe to call `proc "echo" [possibly_malicous_string]`. So it is correct behaviour that you cannot used shell features with `proc`. Any security-aware code should only use `proc` or be very careful when using `shell`. If you want shell features, use `shell` instead of `proc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 10:34:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 10:34:00 -0000 Subject: [GHC] #8811: Profiling output jumbled together Message-ID: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> #8811: Profiling output jumbled together ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In the time profile (-p), if the MODULE column is very wide and the no. column is also very wide they will run together with no space between. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 10:43:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 10:43:18 -0000 Subject: [GHC] #8806: Invalid constraints should fail to type check In-Reply-To: <044.7cbae69d1cf5a8ae601c94fd3e091cbb@haskell.org> References: <044.7cbae69d1cf5a8ae601c94fd3e091cbb@haskell.org> Message-ID: <059.edec8552782cf469761b7defba9da654@haskell.org> #8806: Invalid constraints should fail to type check --------------------------------------------+------------------------------ Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Erik de Castro Lopo ): In [changeset:"55cc01a95328667e5e26f1e3062a45059cc3cbec/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="55cc01a95328667e5e26f1e3062a45059cc3cbec" Add test case for #8806. GHC 7.6.3 and earlier should fail to type check this but don't. This was fixed some time between the 7.6.3 and the 7.8rc1 release, so we're just adding a test to prevent future regressions. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 11:06:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 11:06:40 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.f528b8ca987d6f691fa60ba7cc740861@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by jstolarek): Replying to [comment:6 nomeata]: > Well, if you check where `translate` is being used: It is only used on Windows Hm... looks like you're right. In that case which part of the code quotes parameters to `proc`? Because this clearly is performed at some point. > you are using `proc`, where the main feature is precisely that it is ''not'' being passed through the shell. Ah, now I see. This is poorly documented. Documentation for `proc` says: Construct a `CreateProcess` record for passing to `createProcess`, representing '''a raw command with arguments'''. [highlight by me] My understanding was that "raw command" is supposed to be a shell command. Now I see that `proc` is intended to create a raw process, not a shell command (which is implied by the function's name but certainly not by its documentation). > With proc it is safe to call proc "echo" [possibly_malicous_string] I don't understand this. Could you give example of how possibly_malicous_string could be dangerous (assuming characters are not escaped)? > Any security-aware code should only use proc Please explain why. If I write a Haskell program that runs external command I can do a lot of bad things even when parameters to `proc` are escaped. > If you want shell features, use shell instead of proc Problem with `shell` is that it runs `sh` shell, not `bash`. Replacing `proc` with `shell` in my example code gives: {{{ /bin/sh: -c: line 0: syntax error near unexpected token `(' /bin/sh: -c: line 0: `diff <(echo $FOO) <(echo $BAR)' }}} I don't think this ticket should be closed - this is at least a documentation bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:01:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:01:54 -0000 Subject: [GHC] #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' In-Reply-To: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> References: <045.9c9534ff65a93ccdf374e333958a625a@haskell.org> Message-ID: <060.a8900674213a491482f06182203f166e@haskell.org> #8810: rts/RetainerProfile.c: include missing header for 'markStableTables' -------------------------------------+---------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:02:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:02:15 -0000 Subject: [GHC] #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. In-Reply-To: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> References: <046.eb9ffb917e28899b98fd3ba72e618fba@haskell.org> Message-ID: <061.9326f85003961f865ece5d07404e47c5@haskell.org> #8794: Unresolved @ArSupportsAtFile@ on Solaris distribution. -------------------------------------+------------------------------------ Reporter: kgardas | Owner: kgardas Type: task | Status: closed Priority: lowest | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:02:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:02:37 -0000 Subject: [GHC] #8795: Build fails on Solaris 10 due to missing ranlib In-Reply-To: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> References: <046.495822ff9e185868ba8e5ac4e0a57294@haskell.org> Message-ID: <061.bd1c7f0640f0083465b4aa820543a857@haskell.org> #8795: Build fails on Solaris 10 due to missing ranlib -------------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Building GHC | Difficulty: Easy (less than 1 failed | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in b4eb13d6a42211681774cc859decf9ab5e64ba7f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:03:05 -0000 Subject: [GHC] #8719: clarify prefetch release notes + remove some deadcode In-Reply-To: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> References: <045.5f178de64392be2c9a8f18ae8c9e8bf4@haskell.org> Message-ID: <060.d2f74dcd45570fc121d5a9347496979f@haskell.org> #8719: clarify prefetch release notes + remove some deadcode -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 6c8410d29f6e78c309a6152a62788b3681a3350b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:03:35 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:03:35 -0000 Subject: [GHC] #8764: Usage of `sed' in GHC build system (Solaris build failure). In-Reply-To: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> References: <046.9bb9161d5d4cdcddba6a983920687cb3@haskell.org> Message-ID: <061.336413158904220a9bbeadd16d6d5702@haskell.org> #8764: Usage of `sed' in GHC build system (Solaris build failure). ----------------------------------------+----------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in fd5d7277ec3634989872e2a3f30970633936e1a2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:03:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:03:52 -0000 Subject: [GHC] #8805: QuasiQuote should imply -dynamic-too, too In-Reply-To: <044.384db18e87dddbf21a695e0e04d391b3@haskell.org> References: <044.384db18e87dddbf21a695e0e04d391b3@haskell.org> Message-ID: <059.09f17aa547e46885c9da90a731d89770@haskell.org> #8805: QuasiQuote should imply -dynamic-too, too -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 0eb804b5cec38eabc02eed2498c56575d0503977 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:04:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:04:05 -0000 Subject: [GHC] #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc In-Reply-To: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> References: <045.a10eb6e6ea6f0c47d23d5720434edafc@haskell.org> Message-ID: <060.b56265477ab768afc7eab94fa2483e7b@haskell.org> #8792: doc incorrect: Mac OS X does not supply lllvm i.e. opt and llc -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Documentation | Difficulty: Easy (less than 1 bug | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in a1e57a0fb1979aeec191c35d96e9b98c03be6c47 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:04:28 -0000 Subject: [GHC] #8801: Exclude extralibs from sdist In-Reply-To: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> References: <046.a81ab0f1b9eeb478761b9470721b1e6e@haskell.org> Message-ID: <061.c7b9f03d11dfe67a32683d7f4255d9d0@haskell.org> #8801: Exclude extralibs from sdist -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in cd10cd4b6509a827fb3278d51d2802dfedd24ddc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:04:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:04:49 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.9f8d093394a3139773cd3d4718e6a6ec@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: fixed | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in b27517a53ef4a8cdc62d52289600f02e28a46a7c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:13:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:13:03 -0000 Subject: [GHC] #5682: Properly parse promoted data constructor operators In-Reply-To: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> References: <046.4309c8d10f9ce4f59ada3d5336b248b8@haskell.org> Message-ID: <061.c3c126e6ffabe59c4b2b311ba891d778@haskell.org> #5682: Properly parse promoted data constructor operators -------------------------------------+------------------------------------- Reporter: lunaris | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 (Parser) | Keywords: PolyKinds, ghc- Resolution: fixed | kinds Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Difficulty: Unknown valid program | Blocked By: Test Case: | Related Tickets: #8486 parser/should_compile/T5682 | Blocking: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5a576754d745171422d13cd1dba69dd874714cf1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5a576754d745171422d13cd1dba69dd874714cf1" Add a test for d3af980 (#5682) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:15:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:15:27 -0000 Subject: [GHC] #8806: Invalid constraints should fail to type check In-Reply-To: <044.7cbae69d1cf5a8ae601c94fd3e091cbb@haskell.org> References: <044.7cbae69d1cf5a8ae601c94fd3e091cbb@haskell.org> Message-ID: <059.5f5c30f2fb099a689ac5f571e16a9fb3@haskell.org> #8806: Invalid constraints should fail to type check ------------------------------------------------+-------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8806 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T8806 * resolution: => fixed Comment: Thanks Erik. I'm just adding the test case to the ticket, and closing since it's now done (as I understand it). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:21:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:21:44 -0000 Subject: [GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments In-Reply-To: <044.1b0554fe8d821cf54101cba5a613a396@haskell.org> References: <044.1b0554fe8d821cf54101cba5a613a396@haskell.org> Message-ID: <059.2c11ae54597c8899ed504bea326cd18e@haskell.org> #8808: ImpredicativeTypes type checking fails depending on syntax of arguments ----------------------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Yes, I'm afraid that `ImpredicativeTypes` is a non-feature right now. As I wrote to the GHC users list yesterday: `ImpredicativeTypes` is not properly finished. When I first implemented it I implemented a fairly ambitious design based on "boxy types" (see paper with that in the title). But it proved unsustainably complicated, both in the implementation and indeed for programmers to reason about which programs should be accepted and which should not. So I took most of it out. There are some vestiges but to a first approximation it isn't really there at all. My plan is to do something along the lines of QML (again, look at the paper), plus add explicit type application. But there are always too many other things to do. This is swampy territory, and I have spent more time on it that I care to tell you without producing a design that I am satisfied with. So while I would be very happy if someone wants to start helping, you do need a good grasp of type inference first. It's not a project to learn on. However the ''internal'' intermediate language, Core, is fully impredicative and always has been. No difficulties there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:32:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:32:21 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.9533ac4fa2ab13567ebb57a6f6ff51d0@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Thanks for the heads-up. Can anyone point me to a single write-up of * The basic idea * A specification, as precise as possible. (E.g. given a proposed Core- Core transformation, does the transformation meet the specfification or not? There are a lot of side conditions like "if `tickishSoftScope` then..." in the code.) * An overview of how the implementation works supported by examples. There are lots of related design ideas sketched here [wiki:ExplicitCallStack]. If there's a serious proposal to adopt this one, it would be helpful to have a write up in at least this level of detail, perhaps more. Maybe it exists already. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 12:36:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 12:36:55 -0000 Subject: [GHC] #8802: createProcess implictlitly escapes and quotes command line parameters In-Reply-To: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> References: <048.e746dcc5a956936746b582edb0af0ddd@haskell.org> Message-ID: <063.5bcc9f667165d8d48693df840bd1bb0d@haskell.org> #8802: createProcess implictlitly escapes and quotes command line parameters --------------------------------------+------------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by nomeata): > > Well, if you check where translate is being used: It is only used on Windows > > Hm... looks like you're right. In that case which part of the code quotes parameters to proc? Because this clearly is performed at some point. No, they are not escaped and they need not to be; they are put in separate strings and passed to `execve`. Escaping is only required if you use the shell to execute the program ? if you don?t use the shell, no escaping is required. > > With proc it is safe to call proc "echo" [possibly_malicous_string] > > I don't understand this. Could you give example of how possibly_malicous_string could be dangerous (assuming characters are not escaped)? {{{ possibly_malicous_string = "$(rm -rf /)" }}} > > If you want shell features, use shell instead of proc > > Problem with shell is that it runs sh shell, not bash. Replacing proc with shell in my example code gives: > > /bin/sh: -c: line 0: syntax error near unexpected token `(' > /bin/sh: -c: line 0: `diff <(echo $FOO) <(echo $BAR)' Well, if you want a different shell than your system default, I guess you need to invoke it explicitly: {{{ proc "bash" ["-c", some_bash_script] }}} > I don't think this ticket should be closed - this is at least a documentation bug. I wouldn?t call it a bug; the semantics of `proc` vs. `shell` are quite standard and expected, at least with some background in Unix systems assumed. But of course there is always room for improvement. Any suggestions? Maybe ?Because the command is executed directly, and not via a shell, the arguments do not need to be escaped, but you cannot use shell features like output redirection?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:36:05 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.7390363e3c1bcb34a721ced5dca868ce@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Simon - the best place to start is Peter and David's paper from last year's Haskell Symposium: http://dl.acm.org/citation.cfm?id=2503788 I think the next level of detail is the comments in the code. If you point to places where more explanation is needed, I'm sure Peter will be happy to add it. This is orthogonal to other methods for stack tracing, including the existing cost-centre-stack profiling. What these patches do is establish a best-effort mapping from object code to source code, ''without affecting what code gets generated at all''. It should have zero effect on optimisation - that's the main point. Then we can use the information later to try to make sense of the stack, and for profiling. There are follow-on patches to add support for these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:46:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:46:07 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.6d5fb714ae0027403ff56471e649034e@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"c72e8898447b2a8e55f2d16594b5944c2ae13e24/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c72e8898447b2a8e55f2d16594b5944c2ae13e24" Fix #8754 again. This time, we carefully initialize the GC stats only if they're not already initialized - this way the user can override them (e.g. `+RTS -t --machine-readable`). Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:46:08 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.7ed294b40583dafc24e52c26563e6bd1@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Comment (by Austin Seipp ): In [changeset:"beac5252d444bafb0722bc6d13c6dd2d49a12070/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="beac5252d444bafb0722bc6d13c6dd2d49a12070" Fix installation of ghc-split (#8760) The rules weren't correctly setting INSTALL_TOPDIRS, and on top of that the dependencies were wrong when BINDIST=YES. Authored-by: Evan Hauck Authored-by: Austin Seipp Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:48:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:48:13 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.b577a13b29e83c956dceed58575dac9a@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: new => merge Comment: Fixed in HEAD and in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:48:21 -0000 Subject: [GHC] #8760: ghc 7.8: ghc-split not installed In-Reply-To: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> References: <053.1aa638cbe9ef70b707edba6dde51f26b@haskell.org> Message-ID: <068.81bbc1ac3ed24f1c8f6ac8808583f3e2@haskell.org> #8760: ghc 7.8: ghc-split not installed ------------------------------------------+-------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------+-------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Thanks Evan, I made a fix based on your patch. Merged in HEAD and 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 14:48:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 14:48:25 -0000 Subject: [GHC] #8754: :set +s always says space usage is 0 bytes In-Reply-To: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> References: <045.a034f54c8df64e4035c45fe266ad88ee@haskell.org> Message-ID: <060.3fbf7eab926eaad41a97281f727ea728@haskell.org> #8754: :set +s always says space usage is 0 bytes ---------------------------------+------------------------------------ Reporter: George | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 15:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 15:04:51 -0000 Subject: [GHC] #8812: Make *_stub.c files available again Message-ID: <045.6e7f0d1ca3f060bc68fc22b159c45464@haskell.org> #8812: Make *_stub.c files available again ------------------------------------+------------------------------------- Reporter: ralphb | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In our project we would like to link Haskell functions into C++ code. In principle this works fine using FFI. An additional constraint, however, is that we need to generate and link the object files ourselves. Alas, ghc no longer keeps the *_stub.c files around. (And fishing for files in /tmp is not a viable solution.) I would like to propose an additional command line switch to keep *_stub.c files, as previous compiler versions did by default. (Note that there is an older, similar request #7463, but our use case is much broader than that and not limited to unregistered compilation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 15:06:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 15:06:02 -0000 Subject: [GHC] #8786: libraries/primitive build failure on Solaris 10 In-Reply-To: <046.935806b919fa984f3495fcf0b192593a@haskell.org> References: <046.935806b919fa984f3495fcf0b192593a@haskell.org> Message-ID: <061.dc45cca34966612c3966a1e0c755028d@haskell.org> #8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.8.1-rc1 (other) | Keywords: Resolution: fixed | Architecture: x86_64 (amd64) Operating System: Solaris | Difficulty: Easy (less than 1 Type of failure: Building GHC | hour) failed | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Herbert merged this into the 7.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 15:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 15:06:41 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.0f657c1823a6e3c85c4d18fbe7fce677@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Yes, it would maybe be less confusing if there was a separate ticket for Peter's initial patches. The ticket could be named "Implement an object code to source code mapping" or maybe just "Emit DWARF in NCG". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 15:50:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 15:50:21 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.09d6bde216a3ef099d4328ef8eb058db@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by simonpj): > which breaks the assumption that all the objects of a package are linked into the same shared library Could we not simply drop that assumption? At least when we aren't loading a whole package but instead are doing this "load module and its dependencies" stuff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 16:08:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 16:08:15 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.1dac35132d71f110dd7aaa0b3c7849f4@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): > given a proposed Core-Core transformation, does the transformation meet the specfification or not? Simon covered the basic idea pretty well. From the transformation point of view, the general rule of thumb is that source notes want to stay on covered code (even if transformed), but don't care too much about new code getting added in ("soft scope"). So we can for example work with fusion by simply floating "upwards": {{{ src<1.hs> foldr k z (src<2.hs> build g) ===> src<1.hs> src<2.hs> g k z }}} Cost-centres would disallow this kind of transformation, as the new stacks have little to do with the old one. Source notes on the other hand want the transformation to still happen, so we just annotate the new expression with everything that appeared on the deconstructed source expression. The paper goes into (way) more detail here, but the short version is that while not always optimal, this approach is always legal. The only special case so far is `let`- and `case`-floating, where we run into the same problems as cost-centres (and use pretty much the same solution). Additionally we decide to not care too much about allocation costs at a number of points where it would have made things too messy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 16:13:58 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 16:13:58 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.048ea231c7799bfe1a0d9e43c4c94a68@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I would really, really like a wiki page that explains all this. Reverse- engineering it from a 65-comment trail is very labour intensive. The wiki page can by all means point to the paper (preferably not behind a paywall), explain the principles, etc. That might not take many words -- if so, that's great! Meanwhile I will go back to the paper Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 16:35:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 16:35:41 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc Message-ID: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- ghc-7.8.20140130 complains with {{{ Not in scope: type constructor or class ?Typeable2? Perhaps you meant ?Typeable? (imported from Data.Typeable) }}} changing Typeable2 to Typeable fixes it but is incompatible with ghc-7.6: {{{ Expecting two more arguments to `Gr' In the stand-alone deriving instance for `Typeable Gr' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 16:38:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 16:38:54 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.c9562b252e227e2b9f4a38780e0c1dcc@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by dreixel): * status: new => closed * resolution: => wontfix Comment: `Typeable2` no longer exists. If you need your code to work with both 7.8 and 7.6, you can use `CPP`. There's also `Data.OldTypeable` in 7.8. Some more information: https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 16:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 16:45:32 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.01dd47fb7176ac07438c67d0776939c2@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:14 simonpj]: > > which breaks the assumption that all the objects of a package are linked into the same shared library > > Could we not simply drop that assumption? At least when we aren't loading a whole package but instead are doing this "load module and its dependencies" stuff. It's a compile-time choice, so we can't do one thing for compiling a package and another when running TH. I think it's probably a big performance hit to drop this optimisation (but I don't have measurements). Basically the optimisation means that all the intra-package references can be direct, rather than going via the indirection table. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 17:38:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 17:38:50 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.9d68e9e713cb4cf4bb4a7e9cf9451c6a@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): Perhaps it makes sense to drop the optimization for 7.8-RC2, though, so that testers can find issues that are masked by this one? Patch attached. I've tested that it fixes "cabal install lens" and am currently benchmarking it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 17:39:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 17:39:15 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.8127dbc7a8ea5e12430109df844f46dd@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): An (derived) instance of Data.!OldTypeable.Typeable cannot be used for a context based on Data.Typeable. Therefore Data.!OldTypeable is pretty useless. Is it no option (i.e. better) to make Typeable{1,..,7} behave like Typeable (with a warning)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 17:40:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 17:40:21 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.9ccbadf372f94bc3ab9037be5abc059b@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by rwbarton): (I haven't tried validating that patch, I guess it will probably fail due to `-Werror` because the argument `this_pkg` is now unused.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 21:10:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 21:10:11 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.aab54c6f50f52e29e31e7bc4dfa1da22@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): @maeder, nope, please use CPP. CPP allows us to better support evolving / improving GHC while still ensuring that code can work across multiple GHC versions. Please use it. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 21:33:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 21:33:14 -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.2872c2ca045bb3dcb946fab2f6891ebc@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by lukexi): * cc: lukexi@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 20 22:09:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Feb 2014 22:09:00 -0000 Subject: [GHC] #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread In-Reply-To: <045.61996263d69494df356fa9ae5390b99a@haskell.org> References: <045.61996263d69494df356fa9ae5390b99a@haskell.org> Message-ID: <060.e1c592265a61925ef0bdce8182cc6e33@haskell.org> #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread ------------------------------------------------+-------------------------- Reporter: bholst | Owner: Type: bug | simonmar Priority: normal | Status: closed Component: Runtime System | Milestone: Resolution: invalid | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: This is correct: remember that the weak reference is ''weak'', so it doesn't keep the `MVar` alive, and hence the thread is also not reachable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 01:03:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 01:03:14 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.602e0c39c6a60fa467b5772f36c2f892@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by duncan): So one thought that we were just mulling over in #ghc is... Use bytecode for the local modules in the current package. This already works for GHCi of course. We don't ''have'' to use the .dyn_o files. We do know when we start a `--make` job if we have any modules that use TH/QQ. If we do then we could turn on a mode "compile to bytecode in mem for all modules and spit out object code", a bit like the existing (albeit hacky) `-dynamic-too` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 04:53:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 04:53:59 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.f419bd5e2756a139a3adcadf0ee52215@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): how would that impact compilation time? (using the bytecode versions?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 06:16:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 06:16:43 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly Message-ID: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> #8814: 7.8 optimizes attoparsec improperly ------------------------------+-------------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import qualified Data.Attoparsec.Text as A import Data.Text (Text) import qualified Data.Text as T testParser :: Text -> Either String Int testParser f = fmap length . A.parseOnly (many (A.char 'b' <|> A.anyChar)) $ f main :: IO () main = print . testParser $ T.replicate 50000 "a" }}} On GHC 7.6.3 with `-O2`: {{{ real 0m0.062s user 0m0.022s sys 0m0.007s }}} On GHC 7.8 tip with `-O2`: {{{ real 0m12.700s user 0m12.504s sys 0m0.165s }}} On GHC 7.6.3 with `-O0`: {{{ real 0m0.077s user 0m0.025s sys 0m0.007s }}} On GHC 7.8 tip with `-O0`: {{{ real 0m0.055s user 0m0.026s sys 0m0.007s }}} This seems to be related to the use of `<|>`; if I change the program so that the second branch (`A.anyChar`) is never taken, 7.8 behavior is roughly the same as 7.6 under any optimization level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 07:35:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 07:35:10 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.8f230cce97a3ea5286059d3d036d0ef2@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by tibbe): * cc: bos@?, johan.tibell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 07:36:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 07:36:22 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.487d5f8b8492e9f2f880df8aef30b9e9@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): That's a huge regression. Are you sure all libraries in the GHC tree where compiled with optimization turned on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 07:59:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 07:59:24 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.56a6840234d70a4e43e05e8c32227bb7@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by joelteon): Yeah it is pretty serious. I just cleared out ~/.ghc and reinstalled with "optimization: 2" in my cabal config. Same result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:06:42 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:06:42 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.dbc34a8d96f45606dcfe1a4f5f53d827@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by joelteon): Talked with some people in #ghc. `-fno-full-laziness` eliminates the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:15:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:15:16 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.779ee0374bcfb53c45f60169439ed831@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Can you identify on which module `-fno-full-laziness` makes the difference? Is it just the module above, or do you need to set that flag for `attoparsec` itself? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:16:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:16:37 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.c9a8d7cb517d32f7f1853e776aea2ffc@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by joelteon): Using it when compiling the module above is enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:28:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:28:26 -0000 Subject: [GHC] #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread In-Reply-To: <045.61996263d69494df356fa9ae5390b99a@haskell.org> References: <045.61996263d69494df356fa9ae5390b99a@haskell.org> Message-ID: <060.3f87dbce6cbb39eb80a2943cbb78b71a@haskell.org> #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread ------------------------------------------------+-------------------------- Reporter: bholst | Owner: Type: bug | simonmar Priority: normal | Status: closed Component: Runtime System | Milestone: Resolution: invalid | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by bholst): You mean the waiting thread is garbage collected in this example and that's why the MVar will never be filled? Then keeping the thread reachable through another MVar should do the trick? {{{ import Control.Concurrent import System.Mem.Weak import Data.Maybe import Control.Monad main = do my <- myThreadId m <- newEmptyMVar w <- mkWeakMVar m (return ()) o <- newEmptyMVar _ <- forkIO $ do threadDelay 1000000 n <- deRefWeak w when (isJust n) $ putMVar (fromJust n) () putMVar o () takeMVar m takeMVar o }}} This program has exactly the same output. I understand that the ''MVar m'' is not reachable from the other thread, but nevertheless the main thread is not blocked indefinately on this MVar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:30:06 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.6334ccbcaeb81988706d2ba4fa318e58@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): What is the problem to add (renamed) copies of Typeable (named TypeableN) and add generic instances "TypeableN k => Typeable k" and re-export those via Data.Typeable? This would allow to test unmodified existing code!!! (These intermediate TypeableN classes may be marked to be deprecated later) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:47:22 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.50eb5b4fce0168ee8c8b8af10ddb94d5@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): The biggest single problem is that RC1 has been out some weeks; RC2 is due today; full release next week. Moreover the person (Pedro) who was working on this area is probably heads-down on his ICFP submission (deadline 1 March). There was quite a bit of email traffic on this at the time all this was nailed down (months ago) and no objections. I'm honestly not sure of details of your proposal. Do you want to modify libraries only, or the compiler as well? Would you like to make a patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 08:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 08:49:33 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.df9a04a7b5ae816ba3f66579b8ce6aa1@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Replying to [comment:4 maeder]: > What is the problem to add (renamed) copies of Typeable (named TypeableN) and add generic instances "TypeableN k => Typeable k" and re- export those via Data.Typeable? This would allow to test unmodified existing code!!! > > (These intermediate TypeableN classes may be marked to be deprecated later) I thought about ways to do this before, and never came to a reasonable solution. If you can find one, please let us know. For example, instances like `Typeable1 t => Typeable t` are impossible, as all `t`s match this instance head. I also didn't see how to reconcile the type of the old `typeOF` with the new poly-kinded `typeRep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 09:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 09:10:54 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.6c54b66425f0b50b0f8051caadfb3c7b@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): The other simple alternative is to patch the renamer and rename the class Data.Typeable.TypeableN to Data.Typeable.Typeable. This surely does not reconcile typeOF and typeRep, but hand-written instances have been (sort of) deprecated long before. I'm not familiar with the internals of Data.Typeable but the following is not impossible: {{{ {-# Language FlexibleInstances, UndecidableInstances #-} class Pretty a where pretty :: a -> String instance Show a => Pretty a where pretty = show }}} Furthermore, Data.!OldTypeable should be removed. It's more harmful to provide a second incompatible Typeable class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 09:21:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 09:21:15 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.25ed82dffa8dd2d7683cc204c3346bbc@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Replying to [comment:7 maeder]: > The other simple alternative is to patch the renamer and rename the class Data.Typeable.TypeableN to Data.Typeable.Typeable. > > This surely does not reconcile typeOF and typeRep, but hand-written instances have been (sort of) deprecated long before. > > I'm not familiar with the internals of Data.Typeable Well, I am, and I couldn't find an acceptable solution. But, as I said before, I would very much welcome a better solution. It does have to be fully worked out so that we can judge whether it actually works or not. So please provide a replacement `Data.Typeable` that is better than the current one. > Furthermore, Data.!OldTypeable should be removed. It's more harmful to provide a second incompatible Typeable class. This was provided as a quick way to make old code compile by simply changing the import. It's marked as deprecated, and while it may not be entirely useful because `OldTypeable` and (New)`Typeable` instances are distinct, it can still make some old code work. I don't see it as harmful, but, again, I'm willing to be convinced otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 09:38:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 09:38:23 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.b801d5880134325000df32302565bd11@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): I quick test of adding a Typeable2 class ended with: {{{ libraries/base/Data/Typeable/TypeableN.hs:1:1: Typeable instances can only be derived; replace the following instance: instance [overlap ok] Typeable2 a => Typeable a -- Defined at libraries/base/Data/Typeable/TypeableN.hs:32:10 }}} So, at least, we do not need to worry about hand-written instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 09:57:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 09:57:51 -0000 Subject: [GHC] #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread In-Reply-To: <045.61996263d69494df356fa9ae5390b99a@haskell.org> References: <045.61996263d69494df356fa9ae5390b99a@haskell.org> Message-ID: <060.5a5e4f12c215fe37a510c4fcc327f75d@haskell.org> #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread ------------------------------------------------+-------------------------- Reporter: bholst | Owner: Type: bug | simonmar Priority: normal | Status: closed Component: Runtime System | Milestone: Resolution: invalid | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by ezyang): I suspect you typoed, because `my` becomes dead immediately in your code. An MVar will not keep a thread alive unless the thread is blocked on it. If you force the thread to be live it will not get the exception raised, since the thread now retains the MVar. {{{ import Control.Concurrent import System.Mem.Weak import Data.Maybe import Control.Monad import Foreign.StablePtr main = do my <- myThreadId newStablePtr my m <- newEmptyMVar w <- mkWeakMVar m (return ()) _ <- forkIO $ do threadDelay 1000000 n <- deRefWeak w when (isJust n) $ putMVar (fromJust n) () takeMVar m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 10:03:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 10:03:51 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.89d7fce67849631418d1940f06963660@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by duncan): Replying to [comment:19 carter]: > how would that impact compilation time? (using the bytecode versions?) It'd increase it a bit because we'd have to generate and retain the bytecode. The factors are: * we only need to do it for sets of modules involving TH & QQ * we could do it just for the modules that are dependencies of modules using TH * however we may have to run the pipeline twice because the bytecode generator cannot handle -O results (because of unboxed tuples etc). Though in principle we only need to do that for when you build with -O, and it doesn't have to re-run all stages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 12:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 12:30:56 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.71e743c63de4292f6d2854d18586bea8@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by tibbe): Replying to [comment:6 joelteon]: > Using it when compiling the module above is enough. Could you dump the core and see if you can spot what difference the flag makes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 15:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 15:29:12 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.69ef55a758465ce627cba53709dce3b7@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by carter): Replying to [comment:20 duncan]: Ok, so the bytecode approach gives a "fast path" that avoids the "2 passes" fall back general case? So, eg, a package with unboxed tuples in every module would trigger the fall back case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 16:35:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 16:35:32 -0000 Subject: [GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions In-Reply-To: <048.82b1fcc5113161d6daef1f786f24006e@haskell.org> References: <048.82b1fcc5113161d6daef1f786f24006e@haskell.org> Message-ID: <063.904a69e56d863f4aa6ef4ac3535ca471@haskell.org> #8512: Add flag like '-xc' that only reports uncaught exceptions -------------------------------------+------------------------------------ Reporter: blitzcode | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * cc: miffoljud@? (added) Comment: I'm looking closely at issues related to this for #3693. I believe that the way this will be solved is that you simply control from Haskell-land when a stack trace gets printed or not (from the handler). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 21 17:59:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Feb 2014 17:59:54 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.89ef9d67b505dabf763adf3c65187b61@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): I have not had any time to devote to this. I tried {{{ ghc -O T8814.hs -ddump-simpl -o T8814 }}} with and without `-fno-full-laziness`. Indeed I see the perf difference. The Core from `-ddump-simpl` looks very different. Inside `Main.$wa` you'll see a call to `runSTRep`. The function to which `runSTRep` is applied looks very different. * Without full laziness, it consists of a call to `newArray#` followed by a couple of `memcpy` calls * With full laziness, it has a rather complicated local recursive function that allocates a LOT of memory. I have no idea why. I think it must be to do with optimisations being done by RULES in the text library. If I add `-ddump-rule-firings` and grep for `TEXT` in the rule names, I get {{{ -- With full laziness Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> unfused Rule fired: TEXT tail -> unfused Rule fired: TEXT tail -> unfused -- Without full laziness Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> fused Rule fired: TEXT append -> unfused Rule fired: TEXT append -> unfused Rule fired: TEXT append -> unfused Rule fired: TEXT tail -> unfused Rule fired: TEXT tail -> unfused Rule fired: TEXT append -> unfused }}} So there is clearly a difference. Should that difference have such a massive performance impact? Ask the author of the text library! Why does full laziness have the effect? Well if you have `(\x. map (f x) (map g ys))`, say, full laziness may float out the `map g ys` and then the map/map fusion won't happen. At this point I hope that someone else will take over debugging to find out more. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 22 11:31:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Feb 2014 11:31:42 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.1acc67e2a02eb2eb089e1d24532b2a7a@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by kgardas): * cc: karel.gardas@? (added) * priority: low => normal * status: closed => new * resolution: worksforme => * version: 7.0.4 => 7.6.1 Comment: I'm reopening this issue as I'm able to easily reproduce error: {{{ getFileStatus: interrupted (Interrupted system call) }}} I'm able to get it on both SPARC and x86 Solarises. And on both version 10 and 11.1. The way to reproduce this is simple. Put GHC sources on NFS server. Mount this to SPARC/x86 server and attempt to compile GHC from those NFS mounted sources with `gmake -jN' where N > 1. Concretely I'm using 7.6.2 release for x86 compiled by me and for SPARC compiled by Christian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 22 16:27:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Feb 2014 16:27:52 -0000 Subject: [GHC] #8742: Reuse scavenge_small_bitmap In-Reply-To: <047.b2af75ea313cb91018311595681f61c8@haskell.org> References: <047.b2af75ea313cb91018311595681f61c8@haskell.org> Message-ID: <062.3fe4303b1e08ad12a69c747ef1ebb9cc@haskell.org> #8742: Reuse scavenge_small_bitmap -------------------------------------+------------------------------------ Reporter: Tarrasch | Owner: Tarrasch Type: task | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Hi Simon, Did you have time to look at the "unification" patch I sent? I did not measure its change to performance and it will naturally change the output assembly (but I do not know if for better or for worse). I guess we take a risk that the GC becomes ''slightly'' slower with that patch. But if we do apply it we can safely apply the patch that follows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 22 17:56:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Feb 2014 17:56:34 -0000 Subject: [GHC] #8815: confusing language in error message Message-ID: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> #8815: confusing language in error message ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Late last night I was finding myself very confused by the following (in retrospect obvious error message) {{{ src/Numerical/OpenBLAS/BLAS.hs:41:44: A pattern match on a GADT requires GADTs or TypeFamilies In the pattern: SRow In the pattern: DenseMatrix SRow _ _ _ _ In an equation for ?encodeNiceOrderHelper?: encodeNiceOrderHelper (DenseMatrix SRow _ _ _ _) = encodeOrder BLASRowMajor }}} the error is correct per se, but reading (at least late at night) made me think "wait, how is my type not a GADT or TypeFamily?!!?!" I'm thinking (perhaps ) that ``` A pattern match on a GADT requires GADTs or TypeFamilies `` ` could perhaps be more clearly communicated as ```A pattern match on a GADT requires that GADTs or TypeFamilies Language extensions be enabled in the use site module``` (or something similar) relatedly: whats the current reasoning for why GADT related matching logic isn't enabled in client modules that use GADTs? (i'm not questioning it, just wondering why) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 22 21:10:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Feb 2014 21:10:04 -0000 Subject: [GHC] #8816: Make SPARC registerised again. Message-ID: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> #8816: Make SPARC registerised again. -----------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- It looks like recent GHC switched to unregisterised build on SPARC by default. This is kind of regression with the past GHCs where registerised builds were supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 05:53:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 05:53:44 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.4bbcbe872adf55b7cb5d0930fa12f1f3@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------ Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Improving the prettiness of GHC errors is a great way to make it friendlier for people to pick up Haskell. Punting for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 06:02:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 06:02:22 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.1063b43fc2f7696180cbbb2a06349e07@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by schyler): Most of the other error messages of this form mention the extensions in command line form, i.e. -XGADTs or -XTypeFamilies. Maybe it would be better to keep the error nice and short like so; `A pattern match on a GADT requires -XGADTs or -XTypeFamilies` The `-X` is uniform with all the other errors, and this hints an extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 12:26:43 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 12:26:43 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 Message-ID: <049.587f18ac177eee33d831b7f26473022c@haskell.org> #8817: segmentation fault in 7.8 RC1 ----------------------------------+------------------------------------- Reporter: hamishmack | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I get a segmentation fault if I do the following on OS X... * cabal install cpphs --reinstall --force-reinstall --ghc-options=-rtsopts * cpphs +RTS -A16384 -RTS /usr/include/stdio.h Running in gdb the stack shows we are in stg_ap_0_fast and it looks like it is trying to dereference a pointer value of 0x5000500050000 that is in the rbx register. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 12:32:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 12:32:53 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.3df8d0b23a87fb4312a63adbe502bffa@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by luite): Same problem on linux, tested on Ubuntu 12.04 amd64. Using -A4096 seems to make the program hang instead of producing a segmentation fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 19:51:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 19:51:24 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.413cec14e6a8db32ec51eb7c25ea6f3c@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------ Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I'm afraid I don't quite see what you're getting at. The original post says, "[This modified version] is much easier to visually process than GHC's current messages." My question is: Why, precisely? I don't mean to be defensive or dismissive, but trying to generate grounds for a meaningful conversation. For example, here are a few things that you might be getting at: * Having different colors/font weights (i.e. boldness) makes the error messages more visually interesting and therefore easier to pay attention to and read. * Having blank lines in the middle of single error messages makes them less imposing. * Using position marker in a line below some code is easier to follow than an ever-growing context. * In the example, the type of `f` is given explicitly, so the context in which the error was made is more apparent. Short of re-engineering the entire way that GHC handles error messages, it would certainly be hard to produce exactly the output that you are requesting. But, it may be possible to address bulletpoints like my suggested ones above piecemeal and nudge ourselves in the direction of better errors. It's also worth pointing out that each of the bulletpoints above has reasons "against", such as: * Not every terminal supports these extra modes. In particular, GHC has already had some trouble getting "smart" quotes working in all possible environments (or, indeed, figuring out when to fall back onto dumb quotes). * An automated processor of error messages (that is, an IDE built around GHC) could easily get confused around the blank lines. In fact, I believe I've run into this exact problem when running clang from emacs -- the extra "context-setting" output gets interpreted as fresh warnings. * It's unclear to me, personally, if having the position marker on a separate line is necessarily better than the current output. * The user of a DSL in Haskell is generally unaware of the full, general type of a function they are using. Perhaps including the full type in the error message would make it scarier, not friendlier. In any case, I'm curious to hear more about the specific things GHC can do to improve. I think we all want "better" error messages, but we need to agree on a definition of "better" first. And, the changes should probably be incremental, unless we have an eager volunteer to examine the whole error-message generation mechanism holistically. There is quite a bit of code dedicated to error messages, so this is not a task to be taken on lightly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 20:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 20:00:23 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.d8e53d8a6a4fa5388514195967672c55@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): See very relevant discussion in #3647. It was decided that removing the `-X` from error messages made copy-and-paste into `LANGUAGE` pragmas easier. Perhaps surrounding extensions in error messages with quotes would be a happy medium? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 20:16:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 20:16:30 -0000 Subject: [GHC] #8815: confusing language in error message In-Reply-To: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> References: <045.9dd8ba22cc7c785c6e5e16ae6386def8@haskell.org> Message-ID: <060.30aa96c56b43bbe73138893145c75dfc@haskell.org> #8815: confusing language in error message -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Personally, I would have stuck with the previous `-XTypeFamilies` form in error messages, because it's an unambiguous clue that this is a language pragma. I suppose that (more verbosely) one could say `extension TypeFamilies` in error messages. But this is a user issue, so I didn't protest for #3647. If someone wants to re-open the question and gather opinions from users, I'm happy for GHC to adopt the result. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 23 20:28:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Feb 2014 20:28:17 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.d07c02b2bd4c5fd9850d9ada42f427da@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Comment (by ErlendH): This patch uses the following symbols: - U+201B SINGLE HIGH-REVERSED-9 QUOTATION MARK - U+2019 RIGHT SINGLE QUOTATION MARK Shouldn't the first one be U+2018 LEFT SINGLE QUOTATION MARK to match the right quotation mark? Right now it looks really unbalanced with the fonts I tested. Is this intentional? Here's a screenshot, using Microsoft's Source Code Pro font: [[Image(http://i.imgur.com/RkwwPB6.png)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 08:19:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 08:19:38 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.a880250e544fcb63da43f3d59dc20e3a@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by hvr): * milestone: => 7.8.1 Old description: > I get a segmentation fault if I do the following on OS X... > > * cabal install cpphs --reinstall --force-reinstall --ghc- > options=-rtsopts > * cpphs +RTS -A16384 -RTS /usr/include/stdio.h > > Running in gdb the stack shows we are in stg_ap_0_fast and it looks like > it is trying to dereference a pointer value of 0x5000500050000 that is in > the rbx register. New description: I get a segmentation fault if I do the following on OS X... {{{ cabal install cpphs --reinstall --force-reinstall --ghc-options=-rtsopts cpphs +RTS -A16384 -RTS /usr/include/stdio.h }}} Running in gdb the stack shows we are in `stg_ap_0_fast` and it looks like it is trying to dereference a pointer value of `0x5000500050000` that is in the `rbx` register. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 08:41:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 08:41:03 -0000 Subject: [GHC] #8818: Add withMVarMasked Message-ID: <042.4c26bcf817601d084894084de7c8bf71@haskell.org> #8818: Add withMVarMasked ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We already have `modifyMVarMasked` and `modifyMVarMasked_`, and so I propose to add {{{#!haskell {-| Like 'withMVar', but the @IO@ action in the second argument is executed with asynchronous exceptions masked. /Since: 4.7.0.0/ -} {-# INLINE withMVarMasked_ #-} withMVarMasked :: MVar a -> (a -> IO b) -> IO b withMVarMasked m io = mask_ $ do a <- takeMVar m b <- io a `onException` putMVar m a putMVar m a return b }}} any arguments against this addition? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 09:37:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 09:37:34 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.a92f32760d6711b8fc9cc43176218168@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): Could you test my ghc-7.6.3-i386 solaris bin-dist that contains the above patch, if it solves this (NFS) problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 11:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 11:20:52 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.8fbbf22bf4f938f24ace15aac2ec6fe4@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by kgardas): Do you have a patch? I'm asking since for complete verification I would need to: 1) patch and build 7.6.x (using gmake -j1) 2) patch GHC HEAD and build with (1) using gmake -jX The reason is simple, your offered patch GHC will be used just to build ghc-stage1 + boot libs and this is just a small part of GHC bootstrap. Everything else will go with ghc-stage1 which also needs to be patched. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 13:16:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 13:16:12 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.982ddd131201ef1a4b081f539f14b4f8@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): The patches are just these (as described in comment:24) {{{ -bash-3.2$ diff -u libraries/unix/System/Posix/Files.hsc~ libraries/unix/System/Posix/Files.hsc --- libraries/unix/System/Posix/Files.hsc~ Di Nov 5 15:27:50 2013 +++ libraries/unix/System/Posix/Files.hsc Di Nov 5 15:32:50 2013 @@ -185,7 +185,7 @@ fp <- mallocForeignPtrBytes (#const sizeof(struct stat)) withForeignPtr fp $ \p -> withFilePath path $ \s -> - throwErrnoPathIfMinus1_ "getFileStatus" path (c_stat s p) + throwErrnoPathIfMinus1Retry_ "getFileStatus" path (c_stat s p) return (FileStatus fp) -- | Acts as 'getFileStatus' except when the 'FilePath' refers to a symbolic -bash-3.2$ diff -u libraries/unix/System/Posix/Files.hsc~ libraries/unix/System/Posix/Files.hsc -bash-3.2$ diff -u libraries/unix/System/Posix/Files/ByteString.hsc~ libraries/unix/System/Posix/Files/ByteString.hsc --- libraries/unix/System/Posix/Files/ByteString.hsc~ Di Nov 5 15:28:33 2013 +++ libraries/unix/System/Posix/Files/ByteString.hsc Di Nov 5 15:33:26 2013 @@ -167,7 +167,7 @@ fp <- mallocForeignPtrBytes (#const sizeof(struct stat)) withForeignPtr fp $ \p -> withFilePath path $ \s -> - throwErrnoPathIfMinus1_ "getFileStatus" path (c_stat s p) + throwErrnoPathIfMinus1Retry_ "getFileStatus" path (c_stat s p) return (FileStatus fp) -- | Acts as 'getFileStatus' except when the 'RawFilePath' refers to a symbolic }}} These files contain trailing white spaces (that my editor deleted automatically). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 14:12:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 14:12:53 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.7985fe6824433881cd7a29dcd6b0e3c6@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): http://hackage.haskell.org/package/uni-graphs-2.2.1.0/docs/Graphs- GraphDisp.html contains an example where replacing Typeable1 by Typeable was not enough, because Typeable1 used to fix the kind. I had to add {{{ +{-# LANGUAGE KindSignatures #-} }}} and replace the empty class as follows: {{{ -class Typeable1 nodeType => NodeTypeClass nodeType +class Typeable (nodeType :: * -> *) => NodeTypeClass nodeType }}} So it would make sense to further supply Typeable1, Typeable2, etc. classes with matching kinds. Is there a way to circumvent the above "instances can only be derived" error? Is there a different way to supply TypeableN classes that imply/derive Typeable instances? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 15:26:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 15:26:04 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.0c77f0c02078d2a680430907821565cd@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): Well, I think this is a bit silly?you should just write the kind signature and forget that `Typeable1` ever existed. However, this does appear to work (with `ConstraintKinds`): {{{ type Typeable1 (t :: * -> *) = Typeable t class Typeable1 t => C t -- *Main> :k C -- C :: (* -> *) -> Constraint }}} so I suppose `Data.Typeable` could export such type synonyms `Typeable1`, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 15:32:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 15:32:02 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.3cc53628c7999bd7954cb1c886600e99@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): I'm confused. Can _class_ synonyms be introduced using the keyword "type"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 15:55:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 15:55:26 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.85728e2b1329d1560c0b9978d49e20f3@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by carter): @maeder 1) this ticket is closed 2) if you're having trouble understanding how to work around this, please email haskell-cafe with questions, or ask for help on #haskell on freenode 3) you can use CPP + Reid's suggestion of constraint kinds (http://blog .omega-prime.co.uk/?p=127 is a blog post on them) to emulate having Typeable1 ... N conditionally defined as non polykinded alternatives using constraint kinds. This seems to be more work than just fixing the code mind you :) 4) if you're confused about constraint kinds, ask on haskell cafe mailing list or on #haskell on freenode -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 16:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 16:08:46 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.aa84756b8c77d5a905b81848df0fecf2@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by maeder): * status: closed => new * resolution: wontfix => Comment: If you have such a simple workaround based on !ConstraintKinds why do you break backwards-compatibility nilly-willy at let me waste my time by asking for a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 16:21:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 16:21:29 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.8d3cb4d8efeca65ae5eb525e052367ae@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Guys, lets all be polite! Christian, yes indeed one of the primary motivations for `-XConstraintKinds` was to allow "type" synonyms to include class constraints (and indeed all sorts of constraints). Pedro said "I couldn't find an acceptable solution. But, as I said before, I would very much welcome a better solution." Reid suggested one, perhaps one that Pedro thought of and discarded, perhaps not. It has the advantage that it might be a simple change to `Data.Typeable` making (deprecated) exports of `Typeable1`, `Typeable2` etc. Pedro: can you think of any problems with this? Thanks Reid. If someone would like to try it out and send a patch the validates, it might just make it into 7.8. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 16:29:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 16:29:48 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.6cfb23d7733d509459b12044cc6c3361@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 16:34:39 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 16:34:39 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.25e80c6af41d4dfd89712f3547fe64be@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): I've only added Typeable1 and Typeable2 and did not try to reduce the language extensions required in the attached modules Data.Typeable and Data.Typeable.TypeableN. I even think, these synonyms should not be deprecated since they help useres to avoid kind signatures! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 16:50:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 16:50:08 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.6d47d7eb34150dc3a80deefc55f8a579@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): These constraint kinds will probably not help for i.e. {{{ deriving instance Typeable2 Gr }}} Sigh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 17:33:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 17:33:56 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.baf288fb55330186483d504b2083cb41@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by kosmikus): I think that even if `TypeableN` would be added as `type` synonyms using `-XConstraintKinds`, they should be deprecated. They're ugly and don't add anything except (a limited amount of) backwards compatibility. Adding a kind-signature in a case that'd otherwise be "too" polymorphic is much clearer IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 17:53:24 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 17:53:24 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.f3b74297dd5160d7844900a66acdbb04@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): Christian: actually that does work. That seems like a decent argument to include these type synonyms for backwards-compatibility purposes. (As kosmikus notes, they're still not 100% backwards compatible. For example, `Typeable` still doesn't fix the kind of its argument, which could matter in a module with `PolyKinds`; and since `TypeableN` is now a type synonym it can't be the argument to another type constructor (with `ConstraintKinds`). But those are both fairly obscure cases.) I fully agree though that the type synonyms should be marked as deprecated. `TypeableN` is a hack that served its purpose; now we can express our programs better using orthogonal features (polykinded types and kind signatures). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:03:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:03:42 -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.28ae0ab5c3376d5d201861841701941e@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Ugh, so this is a slightly annoying 'fix' because the compilation options are hashed as part of the recompilation check, and simply loading the dynamic interface file won't work as the hashes will differ (because -dynamic-too implies some other options). I've almost got a working fix for this I think, but it's unclear to me how hacky it might be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:12:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:12:23 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.015751cf32ec1feea114937bbe1d2d3b@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): Ok, deprecate them. When they are finally gone users could add such synonyms later themselves to easily port their old code. (The release notes should refer to solutions using !KindSignatures and !ConstraintKinds.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:21:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:21:35 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.df209f7795e291e09c73f8f222440208@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): The new module Data.Typeable.TypeableN must also be added to base.cabal, as I just realised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:26:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:26:27 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.735d18326cfd85b3ff667ac730a00233@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): I would suggest just adding them to Data.Typeable; wouldn't that allow most uses of Data.Typeable to remain unchanged in 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:30:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:30:55 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.78f40ed804bdffd44b390c8cb2f9688d@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): I don't mind. I just thought it is easier to simply remove the import (and export entries) later on, but ignored the burden of adding and removing files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:53:04 -0000 Subject: [GHC] #8819: Testsuite failures in 7.8 RC1 Message-ID: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> #8819: Testsuite failures in 7.8 RC1 ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64: {{{ Unexpected failures: ../../libraries/base/tests fixed [bad stdout] (normal) ../../libraries/base/tests/Numeric num010 [bad stdout] (normal) ../../libraries/process/tests process007 [bad exit code] (normal) codeGen/should_compile T7574 [stderr mismatch] (normal) codeGen/should_gen_asm memcpy [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal) codeGen/should_run T2838 [bad stdout] (normal) lib/integer integerBits [bad stdout] (normal) lib/integer integerConversions [bad stdout] (normal) numeric/should_run T8726 [bad exit code] (normal) numeric/should_run arith002 [bad stdout] (normal) numeric/should_run arith003 [bad stdout] (normal) numeric/should_run arith004 [bad stdout] (normal) numeric/should_run arith005 [bad stdout] (normal) numeric/should_run arith011 [bad stdout] (normal) numeric/should_run arith012 [bad stdout] (normal) numeric/should_run arith014 [bad stdout] (normal) parser/should_run readRun002 [bad stdout] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/should_run T3736 [bad stderr] (normal) rts T5423 [bad stderr] (normal) rts T7815 [bad exit code] (threaded1) safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 18:57:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 18:57:41 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.79d8c1aec8a63dd6721d2c93fc72ada2@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by thoughtpolice): Reid's fix does in fact work and I'm inclined to go with it for RC2 since it's slightly overdue. I've checked that with the 7.8 branch that `lens` installs properly. After thinking this weekend, I think this should go in. In the mean time, we can think up a better way to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 19:06:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 19:06:06 -0000 Subject: [GHC] #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux Message-ID: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux ----------------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #8819 | ----------------------------------+---------------------------------------- Selfbootstrap of an unregisterised ghc fails on 64 bit PowerPC and AMD but not on 32 bit (PowerPC or Intel): {{{ [10021s] "inplace/bin/ghc-stage1" -static -H32m -O -optc-mminimal-toc -optc-fno-builtin -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o [10021s] ghc-stage1: panic! (the 'impossible' happened) [10021s] (GHC version 7.8.0.20140220 for powerpc64-unknown-linux): [10021s] no ppt [10021s] ct ct: _cj::P64 = P64[(old + 16)]; [10021s] _ck::P64 = R1; [10021s] goto cl; [10021s] [10021s] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I disabled gcc's built in functions through {{{-fno-builtin}}} which got rid of a load of warnings (incompatible types for the built-ins) but still fails as shown above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 19:07:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 19:07:02 -0000 Subject: [GHC] #8819: Testsuite failures in 7.8 RC1 In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.de78f9f83459be7382da83499c723879@haskell.org> #8819: Testsuite failures in 7.8 RC1 ------------------------------------------------+-------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by trommler): * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 19:07:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 19:07:58 -0000 Subject: [GHC] #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux In-Reply-To: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> References: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> Message-ID: <062.34cd17361ac89caa7dc0d668e0f876f2@haskell.org> #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8819 ----------------------------------------+---------------------------------- Comment (by thoughtpolice): Isn't this the same as #8748? If so, it's already fixed in RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 19:23:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 19:23:53 -0000 Subject: [GHC] #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux In-Reply-To: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> References: <047.c9cafcbd66749475d94d7cc187f50c16@haskell.org> Message-ID: <062.e395179413055b35917283bd504d9b21@haskell.org> #8820: 7.8 RC1 unregisterised fails selfbootstrap on 64 bit Linux ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8819 ----------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:1 thoughtpolice]: > Isn't this the same as #8748? If so, it's already fixed in RC2. No it isn't. I'm at commit 8a2989c5df76712d5cd52ff918d4e6c1a741a90b and I managed to bootstrap RC2 up to that commit. This ticket is about self-bootstrapping using RC2 which I did for openSUSE's ghc so far. IIRC a selfbootstrapped ghc is required because of ABI changes between releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 20:14:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 20:14:34 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.61fb1cdb65974cd3f5772319b9535ec4@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"ed1aced403b50f1a15fbe06cc7eeca5b23e69e37/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ed1aced403b50f1a15fbe06cc7eeca5b23e69e37" Fix #8696 - don't generate static intra-package references. See the comments in Packages.lhs and the ticket for some more explanation. This is a temporary fix while we consider a way to re-enable intra-package references in the mean time. Authored-by: Reid Barton Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 22:55:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 22:55:23 -0000 Subject: [GHC] #8821: Functional dependency coverage check does not use type equalities Message-ID: <044.fc51a60e70c3b4ddd75416381ea018a7@haskell.org> #8821: Functional dependency coverage check does not use type equalities -------------------------------------------+------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When checking the coverage condition to validate an instance, we should also consider equality constraints because they have a dependency in both directions. {{{ class C a b | a -> b instance (a ~ b) => C a b -- Illegal instance declaration for ?C a b? -- The coverage condition fails in class ?C? -- for functional dependency: ?a -> b? -- Reason: lhs type ?a? does not determine rhs type ?b? -- Using UndecidableInstances might help -- In the instance declaration for ?C a b? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 23:10:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 23:10:34 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.198796d7a0e2e61542d3f62321bcf887@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Changes (by thoughtpolice): * priority: highest => high Comment: This is now in the 7.8 branch. I'm dropping the priority but not closing or punting this ticket off, since it's at least mitigated a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 24 23:36:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Feb 2014 23:36:51 -0000 Subject: [GHC] #8821: Functional dependency coverage check does not use type equalities In-Reply-To: <044.fc51a60e70c3b4ddd75416381ea018a7@haskell.org> References: <044.fc51a60e70c3b4ddd75416381ea018a7@haskell.org> Message-ID: <059.fb2f967d38815226917a27f9700f4260@haskell.org> #8821: Functional dependency coverage check does not use type equalities --------------------------------------------+------------------------------ Reporter: glguy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by glguy): * status: new => closed * resolution: => invalid Comment: Iavor explained that Undecidable Instances is allowing the functional dependency to consider the context and that the test is working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 03:44:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 03:44:25 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.111a36c096503282c26e2ca599eb747c@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by goldfire): I've tracked this one down, I know exactly what's going wrong, and I know how to fix this particular case, but I'm worried that this may be representative of a class of errors, and I'm not sure how to fix the lot of them. The problem is that !SetLevels, while doing various core transformations (which I don't yet understand), builds up a substitution. This subst is applied as the `CoreExpr` tree is traversed. But, some bits are crucially left out. The bug in this report is because the binder of a `case` statement is left out -- its type is a type variable, but the type variable is substed during the transformation. The result: a binder whose type contains an out-of-scope type variable. The solution, of course, is to make sure to apply the subst to the binder's type. For example, the following works: {{{ = do { let substed_bndr = setVarType case_bndr (substTy (le_subst env) (varType case_bndr)) case_bndr' = TB substed_bndr bndr_spec }}} These lines should be in place of the current line 385, which sets `case_bndr'` without a subst. But, a casual look around tells me that lambda-bound binders are also seemingly left out of the substitution, and I see that there is a `cloneVar` function which seems to be applying the subst. Perhaps the fix should use `cloneVar`. In any case, there's more going on here than I feel comfortable fiddling with, but a cognoscente should be able to use my detective work to squash the bug in rather little time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 04:58:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 04:58:25 -0000 Subject: [GHC] #8822: Allow -- ^ Haddock syntax on record constructors Message-ID: <047.9e31292a58062fe675a519afe89cb025@haskell.org> #8822: Allow -- ^ Haddock syntax on record constructors -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Original ticket is on Haddock Trac [http://trac.haskell.org/haddock/ticket/144 here] which I'm opening here as it requires lexer/parser changes. The idea is that given something like {{{ -- | A tree with labeled internal nodes data Tree = Empty -- ^ Leaf | Branch -- ^ Internal node { label :: a -- ^ Node label , subtrees :: [Tree] -- ^ List of subtrees } }}} we'd like it to parse as the user would expect instead of failing. We're currently forced to do something like {{{ -- | A tree with labeled internal nodes data Tree = Empty -- ^ Leaf | -- | Internal node Branch { label :: a -- ^ Node label , subtrees :: [Tree] -- ^ List of subtrees } }}} which is quite ugly. I can't think of a reason why the first form wouldn't be allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 08:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 08:04:28 -0000 Subject: [GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' In-Reply-To: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> References: <043.cbe6919f438ad52f7a7c1b87d59cd82e@haskell.org> Message-ID: <058.939f7866bf5c58a0cbc4281a60081d97@haskell.org> #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' -----------------------------+---------------------------------- Reporter: Kata | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+---------------------------------- Comment (by simonmar): While this change is in, someone could measure how much effect it has on runtime and binary sizes. Since we still default to static linking, perhaps we can live with a performance hit for dynamic code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 09:52:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 09:52:48 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.9e93df99a9d3f6aa269ce0e25b30da7d@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Pedro, any comments about this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 09:53:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 09:53:25 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.83f0b3d5d3a5970e7597daaa02db5f76@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Yes, I'm working on it, will comment later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 09:53:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 09:53:45 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.691f6380f2f83ecbda65d968b5aece70@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by dreixel): * owner: => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:23:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:23:18 -0000 Subject: [GHC] #8818: Add withMVarMasked In-Reply-To: <042.4c26bcf817601d084894084de7c8bf71@haskell.org> References: <042.4c26bcf817601d084894084de7c8bf71@haskell.org> Message-ID: <057.71c67c744dd852b7e6a7796b532f85d7@haskell.org> #8818: Add withMVarMasked -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"2d5471cd3ee42406042a030424a1a83308a170fa/base"]: {{{ #!CommitTicketReference repository="base" revision="2d5471cd3ee42406042a030424a1a83308a170fa" Add `withMVarMasked` (re #8818) Like `withMVar`, but the @IO@ action in the second argument is executed with asynchronous exceptions masked. This completes the `MVar` API, which already contained `modifyMVarMasked` and `modifyMVarMasked_`. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:33:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:33:00 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.f9804414987c2fdef319131b2a2f657b@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Jose Pedro Magalhaes ): In [changeset:"a5383f7400d05a758094578da28d958fb694b726/base"]: {{{ #!CommitTicketReference repository="base" revision="a5383f7400d05a758094578da28d958fb694b726" Provide Typeable1..7 as type synonyms (see #8813) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:33:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:33:46 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.cdee6f55b3e4b1a2a832f4b53593dba6@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by dreixel): * status: new => merge Comment: Replying to [comment:15 simonpj]: > Pedro said "I couldn't find an acceptable solution. But, as I said before, I would very much welcome a better solution." Reid suggested one, perhaps one that Pedro thought of and discarded, perhaps not. It has the advantage that it might be a simple change to `Data.Typeable` making (deprecated) exports of `Typeable1`, `Typeable2` etc. > > Pedro: can you think of any problems with this? Thanks Reid. No, I hadn't thought of this before, and no, I don't see any problems with it. As has been pointed out already, it won't work for all old code. But it might still make some more code work, and I don't see a problem with including it. So I submitted a patch to base adding those. In particular, the original problem code described in this ticket should now compile (along with a deprecation warning). I've also updated the wiki page at https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable to refer to 7.8 as the present, not the future, and I've added a section on how to make your code compile again. I've also added a link to this wiki page from the Data.Typeable haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:42:17 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:42:17 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.a6ff393aa77c141782dee0884e8f4eda@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel ): In [changeset:"018676c7f883886b388652c913c99a10d2591b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="018676c7f883886b388652c913c99a10d2591b0b" Use U+2018 instead of U+201B quote mark in compiler messages This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019) and therefore looks more familiar on the console. This addresses #2507. Signed-off-by: Herbert Valerio Riedel }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:44:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:44:24 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.8b1466751d2399380983c73817ef0921@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Pedro: Fantastic, thank you. Did you run validate? Austin: please merge to the stable branch. Reid: thank you for the idea! Christian: I hope this makes things better for you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:45:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:45:03 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.219fa27b4887d6975e9e7b4a57a55d6d@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: merge Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * status: patch => merge Comment: I'm setting this ticket to `merge` to have this considered for merging into GHC 7.8 (meaning, I'll leave the decision up to Austin :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 10:46:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 10:46:24 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.0ced1786329f82ef6f2c9fd51f055226@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Replying to [comment:29 simonpj]: > Pedro: Fantastic, thank you. Did you run validate? Yes, it passed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:03:08 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:03:08 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.dddea6189b6d4cdcddc76701050e2e04@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: merge Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Comment (by hvr): FYI, just found this related article [http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html ASCII and Unicode quotation marks], which is summarised as follows: > Please do not use the ASCII grave accent (0x60) as a left quotation mark together with the ASCII apostrophe (0x27) as the corresponding right quotation mark (as in `quote'). Your text will otherwise appear rather strange with most modern fonts (e.g., on Windows and Mac systems). Only old X Window System fonts and some old video terminals show ASCII 0x60/0x27 as left and right quotation marks, while most modern systems follow the ISO and Unicode standards instead. > > If you can use only ASCII?s typewriter characters, then use the apostrophe character (0x27) as both the left and right quotation mark (as in 'quote'). If you can use Unicode characters, nice directional quotation marks are available in the form of characters U+2018, U+2019, U+201C, and U+201D (as in ?quote? or ?quote?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:09:14 -0000 Subject: [GHC] #8818: Add withMVarMasked In-Reply-To: <042.4c26bcf817601d084894084de7c8bf71@haskell.org> References: <042.4c26bcf817601d084894084de7c8bf71@haskell.org> Message-ID: <057.5be3a6973fe8159488d720f09f7bb340@haskell.org> #8818: Add withMVarMasked -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.1 Comment: I went ahead with this (after simonmar confirmed to me on IRC this addition made sense). Also, this has been merged in the ghc-7.8 branch via [a91d68221ca30/base] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:18:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:18:10 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.93eaea74082a5ba44ab73a7cdb48883a@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): Thanks, guys, I hope this makes things better also for other (less language extensions aware) users. Christian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:33:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:33:00 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.009974ef43c1b57df7431447f620095b@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): looking at `Data/Typeable/Internal.hs` in the above patch I see that there are two blocks of language extension pragmas, before and after the haddock header, which is a bit confusing as I expected !ConstraintKinds to be near !KindSignatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:35:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:35:34 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.a679743a7b0c4af4c3778a3d60d7399d@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by Jose Pedro Magalhaes ): In [changeset:"eea1b6f5fe254b249acc618ef5a82c3e52a27f8c/base"]: {{{ #!CommitTicketReference repository="base" revision="eea1b6f5fe254b249acc618ef5a82c3e52a27f8c" Language extension wibble (see #8813) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:35:50 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:35:50 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.2ff9d151601098e9edbfedda28041862@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Oh, yes. Fixed, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:39:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:39:55 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.c8b100b2350e98dec0adef94af7b80c7@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): Thanks and sorry again, but should not all language pragmas be on top of the file (before the haddock header)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:42:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:42:57 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.7f59d8fcadd081863e447a48bb704a52@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): I'm not sure why the `Unsafe` is separate. I guess that was added during some `SafeHaskell` sweep. I'd prefer if they are all together, yes, but that should probably be done in one go to all the modules in base, at least (I suspect `Data.Typeable.Internal` might not be the only module with this problem...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 11:57:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 11:57:40 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.715aff47d49f04ba275d05925c2b8cb8@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by maeder): `Unsafe` being separate at the top of the file actually suggests that all language pragmas should be on top of the file. (But that's a subject of a style guide.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 12:01:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 12:01:40 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.622abf8eb6da621068324f2b0499a05d@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: merge Priority: normal | Milestone: Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by dreixel): Yes. That should be a separate ticket, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 13:41:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 13:41:11 -0000 Subject: [GHC] #8823: showFloat for higher precision types produces strange results for some values Message-ID: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> #8823: showFloat for higher precision types produces strange results for some values --------------------------+------------------------------------------------ Reporter: axman6 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.8.1-rc1 Prelude | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I've written a library which is a quda-double type a la the QD C/C++ package, and showFloat does not behave correctly for numbers with such high precision. My type has ~212 bits of precision, and when using showFloat from Numeric, I get strange results for integer values: {{{ show (1 :: QDouble) = "0.00000000000000000000000000000000000000000000001e47" show (1.1 :: QDouble) = "1.1" show (1000 :: QDouble) = "0.00000000000000000000000000000000000000000000001e50" -- These seems to suggest it happens for any number with only a -- few high bits set to 1 in the result of decodeFloat show (1.125 :: QDouble) = "0.00000000000000000000000000000000000000000000001125e47" show (1.625 :: QDouble) = "0.00000000000000000000000000000000000000000000001625e47" }}} The problem seems to be related to the result of floatDigits, which starts causing problem when it's larger than 56 (floatDigits x, show x): {{{ (56,"1.0") (57,"01.0") (60,"001.0") (212,"0.00000000000000000000000000000000000000000000001e47") }}} My fix has been to use a modified version of showFloat from Numeric by changing the floatToDigits function to include a fix for times when large numbers of zeros are produced: {{{ fixup2 (xs,k) = let (zs,ys) = span (==0) xs in (ys,k-length zs) in fixup2 (map fromIntegral (reverse rds), k) }}} This fixes the symptom but not the issue itself (though it seems like a reasonable thing to have any result returned by floatToDigits. I have attached as minimal test case as I could come up with. Using floatToDigits from Numeric causes the strange behaviour, while floatToDigits' included in the test case does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 13:45:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 13:45:06 -0000 Subject: [GHC] #8823: showFloat for higher precision types produces strange results for some values In-Reply-To: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> References: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> Message-ID: <060.9b841c215a138ce04dbed124f5b3cf31@haskell.org> #8823: showFloat for higher precision types produces strange results for some values ------------------------------------------------+-------------------------- Reporter: axman6 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by axman6): To reproduce the bug, try changing the value of floatDigits to ~56 and running `floatToDigits 10 {FOne,FOneThousand,FTwo}`. As can be seen with FPi the correct results are produced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 14:02:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 14:02:16 -0000 Subject: [GHC] #8823: showFloat for higher precision types produces strange results for some values In-Reply-To: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> References: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> Message-ID: <060.9b694d1bda8b6e8418a70d9e168354e3@haskell.org> #8823: showFloat for higher precision types produces strange results for some values ------------------------------------------------+-------------------------- Reporter: axman6 | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Prelude | Version: Resolution: invalid | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Your `RealFloat` instance is invalid. See the documentation for `decodeFloat`: > If decodeFloat x yields (m,n), then x is equal in value to m*b^n^, where b is the floating-point radix, and furthermore, either m and n are both zero or else '''b^(d-1)^ <= abs m < b^d^, where d is the value of floatDigits x'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 14:10:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 14:10:38 -0000 Subject: [GHC] #8823: showFloat for higher precision types produces strange results for some values In-Reply-To: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> References: <045.40c750adeb6892a521e6a7f77e377fa4@haskell.org> Message-ID: <060.61f98b6141ea1318e2222e7eca883556@haskell.org> #8823: showFloat for higher precision types produces strange results for some values ------------------------------------------------+-------------------------- Reporter: axman6 | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Prelude | Version: Resolution: invalid | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by axman6): Hmmm, it seems you're right, but nonetheless my implementation of decodeFloat is the only one that makes sense for my type since it can represent more than 212 bits of data (for example 1.0000000...005 is represented with the doubles 1.0 and 0.5eN, and 0 for the two other doubles]). It seems that perhaps in my case I may need floatDigits to be very large indeed or use another method to show the number. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 15:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 15:07:41 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.a1db8dd0b06686d37325cc4517f393ba@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: Replying to [comment:33 hvr]: > I'm setting this ticket to `merge` to have this considered for merging into GHC 7.8 (meaning, I'll leave the decision up to Austin :-) after conferring with Austin, I've merged this into ghc-7.8 as [ebb9bd36b80040dc/ghc] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 15:21:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 15:21:01 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken Message-ID: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Specifically the clone works, but then `./sync-all get` fails; {{{ Cloning into 'libraries/Cabal'... fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found Clone of 'https://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed }}} It was broken by b755c7bd6af9f2bee47427b1eaa6c29c72b2b17a which (around lines 587-588) assumes the protocol is `git://`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 15:34:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 15:34:11 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.a89da1bebc0fd1c865f10a964cf094d1@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Changes (by hvr): * milestone: 7.6.2 => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 16:36:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 16:36:45 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.eaeed39c242e9ef905b24fc84327ac7c@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: Replying to [comment:27 Jose Pedro Magalhaes ]: > In [changeset:"a5383f7400d05a758094578da28d958fb694b726/base"]: > {{{ > #!CommitTicketReference repository="base" revision="a5383f7400d05a758094578da28d958fb694b726" > Provide Typeable1..7 as type synonyms (see #8813) > }}} This has been merged in the ghc-7.8 branch via [84aad16f054fe8c7b/base] Is there anything left to be done for the release notes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 16:37:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 16:37:27 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.ab438e1649b20356e993e56aa31d306e@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by hvr): * component: Compiler => libraries/base * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 19:08:33 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 19:08:33 -0000 Subject: [GHC] #8824: cloning from https://github.com/ghc/ghc.git is broken In-Reply-To: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> References: <047.bf80aa4bc9284b8457734954864c0aac@haskell.org> Message-ID: <062.c4c0cf256720c3ffc969a9437b6da926@haskell.org> #8824: cloning from https://github.com/ghc/ghc.git is broken -------------------------------------+------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Same deal for cloning over SSH: http://lpaste.net/100385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 25 20:47:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Feb 2014 20:47:09 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale Message-ID: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Current ghc spits warnings time to time: {{{ : Warning: Couldn't figure out linker information! Make sure you're using GNU gcc, or clang }}} It's because my default locale is '''LANG=ru_RU.UTF-8''' [1] {{{ ... gcc ?????? 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} versus '''LANG=C''' {{{ ... gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [1]: {{{ $ gcc -v ???????????? ?????????? ????????????. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper ??????? ???????????: x86_64-pc-linux-gnu ????????? ????????????: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog ?????? ???????????????: posix gcc ?????? 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [2]: While LANG=C output: {{{ $ LANG=C gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Thread model: posix gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 01:42:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 01:42:01 -0000 Subject: [GHC] #8813: further support deriving instances Typeable1, Typeable2, etc In-Reply-To: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> References: <045.6762f1197f8c3128d07d6fd948422b92@haskell.org> Message-ID: <060.66266bf9c2e08edcf3ee978cb71dad14@haskell.org> #8813: further support deriving instances Typeable1, Typeable2, etc ----------------------------------------------+---------------------------- Reporter: maeder | Owner: dreixel Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: Resolution: fixed | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by George): It seems this fix might allow quickspec to compile unmodified in RC2. In RC1 it fails with {{{ [ 3 of 20] Compiling Test.QuickSpec.Utils.Typeable ( src/Test/QuickSpec/Utils/Typeable.hs, dist/build/Test/QuickSpec/Utils/Typeable.o ) src/Test/QuickSpec/Utils/Typeable.hs:9:59: Not in scope: type constructor or class ?T.Typeable1? Perhaps you meant ?T.Typeable? (imported from Data.Typeable) src/Test/QuickSpec/Utils/Typeable.hs:9:72: Not in scope: type constructor or class ?T.Typeable2? Perhaps you meant ?T.Typeable? (imported from Data.Typeable) Failed to install quickspec-0.9.2 }}} Just thought you might want to know of examples where this fix is indeed helpful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 05:02:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 05:02:50 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.84b4a97e517865484b8e4a5ddfcd13d1@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by juhpetersen): So `LANG=C ghc ...` or `LANG=en_US.utf8 ghc ...` do not give the warning? (possibility `s/ghc/cabal/` etc) I suspect it would be better to give an explicit example of how to reproduce the warning. What version of binutils (for GNU ld) do you have installed? I don't think I have seen this on Fedora anyway, so it sounds like it could be a Gentoo specific issue perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 06:42:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 06:42:46 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.c4fcbb7adff672e971c4913ff4147ba8@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): Replying to [comment:1 juhpetersen]: > So `LANG=C ghc ...` or `LANG=en_US.utf8 ghc ...` do not give the warning? Yes, LANG=C "fixes" it. > I suspect it would be better to give an explicit example of how to reproduce the warning. > What version of binutils (for GNU ld) do you have installed? ghc's warning explicitely says about 'gcc' / 'clang'. I don't think it matters, but it's '''binutils-2.24'''. Once I'll manage to filter out which exactly file triggers it from 9 parallel building threads I'll post a minimal example. I thought error message is obvious enough, but whatever: '''compiler/main/SysTools.lhs''' {{{ -- See Note [Run-time linker info]. getCompilerInfo' :: DynFlags -> IO CompilerInfo getCompilerInfo' dflags = do let (pgm,_) = pgm_c dflags -- Try to grab the info from the process output. parseCompilerInfo _stdo stde _exitc -- Regular GCC | any ("gcc version" `isPrefixOf`) stde = return GCC -- Regular clang | any ("clang version" `isPrefixOf`) stde = return Clang ... -- Process the executable call info <- catchIO (do (exitc, stdo, stde) <- readProcessWithExitCode pgm ["-v"] "" -- Split the output by lines to make certain kinds -- of processing easier. parseCompilerInfo (lines stdo) (lines stde) exitc ) (\err -> do debugTraceMsg dflags 2 (text "Error (figuring out compiler information):" <+> text (show err)) errorMsg dflags $ hang (text "Warning:") 9 $ text "Couldn't figure out linker information!" $$ text "Make sure you're using GNU gcc, or clang" return UnknownCC) return info }}} > I don't think I have seen this on Fedora anyway, so it sounds like it could be a Gentoo specific issue perhaps. Gentoo does not do translation to russian on it's own. What locale do you use on Fedora? Do you have non-english locale installed for gcc? That should be easy to check: {{{ LANG=ru_RU.UTF-8 gcc -v 2>&1 | tail -n1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 07:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 07:17:46 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.711bfea14b6a6832736690b9fccb9eaf@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by slyfox): And the example extracted from base package: {{{ -- cat A.hs {-# LANGUAGE CApiFFI #-} module A where import Foreign.C foreign import capi unsafe "stdio.h value SEEK_END" sEEK_END :: CInt }}} {{{ $ ghc --make A.hs -fforce-recomp [1 of 1] Compiling A ( A.hs, A.o ) : Warning: Couldn't figure out linker information! Make sure you're using GNU gcc, or clang }}} {{{ $ LANG=C ghc --make A.hs -fforce-recomp [1 of 1] Compiling A ( A.hs, A.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 08:28:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 08:28:58 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.dd8f3c0498cfc333efd6ce68c9c3efd0@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by hvr): * cc: simonmar (added) * owner: => simonmar * component: Compiler => Runtime System Comment: I suspect this is actually GC/RTS related; when using `-A4096`, the output of `+RTS -S` looks as below (I had to `CTRL-C` as it won't stop otherwise): {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 1256 1232 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) 0 1208 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.00 0.00 0 0 (Gen: 0) ... 0 0 1224 0.00 0.00 0.98 0.98 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.98 0.98 0 0 (Gen: 0) 0 0 1224 0.00 0.00 0.98 0.98 0 0 (Gen: 0) 72 72 1296 0.00 0.00 0.98 0.98 0 0 (Gen: 0) cpphs: interrupted 1024 0.00 0.00 2,352 bytes allocated in the heap 2,512 bytes copied during GC 6,968 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 215256 colls, 0 par 0.29s 0.29s 0.0000s 0.0000s Gen 1 0 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s INIT time 0.00s ( 0.00s elapsed) MUT time 0.69s ( 0.70s elapsed) GC time 0.29s ( 0.29s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.98s ( 0.98s elapsed) %GC time 29.3% (29.1% elapsed) Alloc rate 3,390 bytes per MUT second Productivity 70.7% of total user, 70.8% of total elapsed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 08:35:13 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 08:35:13 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.a68cd0e55183d08e807b63549b43a184@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by simonmar): Well -A4k/-A16k is a bit silly, but it should work. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 08:58:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 08:58:01 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.fe4d0a7da3f9798b235b975ef9b798ef@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by luite): Hamishmack and me were debugging the random GHCJS segfaults we we've been having for a while, trying to reproduce them with a smaller program, and then stumbled into this. So I hope the fix for this will also affect non- silly scenarios :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 09:37:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 09:37:25 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.e01a14dd01dfed8055d6af9108578145@haskell.org> #8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Changes (by darchon): * related: => #8763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 11:29:53 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 11:29:53 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.360ff478eb4ef9d10faf91e6bef34c57@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by kgardas): * status: new => patch * version: 7.6.1 => 7.9 * milestone: 7.6.2 => Comment: I've tested the patch on Solaris/sparc while building GHC from NFS Solaris drive and it runs fine even with gmake -j32 which always fails without the patch. I've attached git patch for easy merging to HEAD. Thanks for review and Christian for providing it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 16:07:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 16:07:03 -0000 Subject: [GHC] #8822: Allow -- ^ Haddock syntax on record constructors In-Reply-To: <047.9e31292a58062fe675a519afe89cb025@haskell.org> References: <047.9e31292a58062fe675a519afe89cb025@haskell.org> Message-ID: <062.b7b26e6ca26c36117741e48468165c44@haskell.org> #8822: Allow -- ^ Haddock syntax on record constructors -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Parser) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by goldfire): * difficulty: Unknown => Moderate (less than a day) Comment: I took a look at this, and it requires more happy-fu than I've got at the moment. Suppose that we implemented parsing as requested, Then, the problem is that the parser gets mightily confused when it sees {{{ data Foo = Bar -- ^ urk }}} What should it expect next? A `|` and another constructor? Or a `{` and a list of fields? Given the current way constructors are parsed (as ''types'', to allow the possibility of infix constructors), there's not an easy way to restructure things to answer this question (that I can see). On the plus side, I think that solving this problem would make it easier to implement something I've wanted: the ability to annotate individual constructor arguments, like so: {{{ data Foo = Bar Int -- ^ urk Double -- ^ blah }}} which would currently be difficult to parse. If someone wants to restructure this section of the parser, please go for it! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 17:26:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 17:26:25 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell Message-ID: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> #8826: Allow more coercions in Safe Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose we have {{{ newtype Age = MkAge Int }}} and we have `m :: Map String Int`. Is `coerce m :: Map String Age` allowed in Safe Haskell? Currently, no, because of the need to have `Map`'s constructor visible at the cite of the coercion. Why do we need this? In order to forestall any possible abstraction breaking. See [https://ghc.haskell.org/trac/ghc/ticket/8745#comment:3 this comment] for more information. But, it would seem that if the writer of `Map` supplies a role annotation, all should be forgiven. The author of the data structure is saying, with `type role Map nominal representational` that it is OK to coerce the second parameter. The annotation means that the author has considered roles and knows what the roles imply. So, I propose this: We allow coercions in Safe Haskell when the following algorithm permits it (and if the coercion is otherwise type-safe): Traverse down the tree of datatype definitions starting at the datatype to be coerced. At every datatype use, check if that datatype has a role annotation. If so, permit the coercion. Otherwise, require all constructors of the datatype to be in scope and recur on any datatypes mentioned in those constructors. Under that algorithm, we quickly discover that `Map` has a role annotation and permit (type-safe) coercions straightaway. This proposal is strictly a loosening of the current rules, and would allow strictly more programs to be accepted as Safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 17:40:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 17:40:27 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.2d45cbfb200ce546df6d6df2ffd5cc79@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): Did this fix also export `coerce` from a Trustworthy module? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 17:52:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 17:52:16 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong Message-ID: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following modules: {{{ module A (List, ints) where data List a = Nil | Cons a (List a) infixr 4 `Cons` ints :: List Int ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil }}} {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype Age = MkAge Int deriving C class C a where cList :: List a instance C Int where cList = ints }}} {{{ {-# LANGUAGE Safe #-} module C (ages) where import A import B ages :: List Age ages = cList }}} Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!) If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent "constructors-must-be-in-scope" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place. You may also want to read the commentary on #8745 for related discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 18:11:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 18:11:27 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.6f874119441b77a1cfafa5928d7ef5e3@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thoughtpolice): Ah, no, it did not. I forgot that. We can still do this under the caveat that `coerce` is still experimental, but I'm literally making the RC2 srcdist as we speak... So it'll have to wait for the final release at best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 18:47:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 18:47:41 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.695654a6e42ddc8e651ca8b3e30b901c@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by goldfire): * status: closed => new * resolution: fixed => Comment: Reopening the ticket, as without a Safe way of importing coerce, this issue isn't fully solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 19:41:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 19:41:10 -0000 Subject: [GHC] #8807: Variable constraints not handled properly in TH In-Reply-To: <047.bf644d2dcafed70da75aadeef4a4e28b@haskell.org> References: <047.bf644d2dcafed70da75aadeef4a4e28b@haskell.org> Message-ID: <062.d1940d3386312f3d3a4f8a9574dbe272@haskell.org> #8807: Variable constraints not handled properly in TH -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Richard Eisenberg ): In [changeset:"98b6756b09194352aa2ccfbb624992150a7a3520/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="98b6756b09194352aa2ccfbb624992150a7a3520" Fix #8807. It turns out that the enhanced repPred function in DsMeta assumed that the head of any constraint would be a tycon. This assumption is false. Happily, the solution involved *deleting* code. I just removed repPred in favor of repTy, and added the HsEqTy case to repTy, where it should be anyway. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 19:41:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 19:41:45 -0000 Subject: [GHC] #8807: Variable constraints not handled properly in TH In-Reply-To: <047.bf644d2dcafed70da75aadeef4a4e28b@haskell.org> References: <047.bf644d2dcafed70da75aadeef4a4e28b@haskell.org> Message-ID: <062.c0787f3e6eb32b0fe6da992341ea769a@haskell.org> #8807: Variable constraints not handled properly in TH -------------------------------------+------------------------------------ Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 20:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 20:52:45 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.067979603202a8b37915ce4e97d41627@haskell.org> #7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Changes (by trommler): * cc: ptrommler@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 22:19:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 22:19:59 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.45db75453444125caeb3ce63da64d1e1@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"d7bff4dddfa10389156ca11f75a5a23e78cf3ab0/integer-gmp"]: {{{ #!CommitTicketReference repository="integer-gmp" revision="d7bff4dddfa10389156ca11f75a5a23e78cf3ab0" Fix GMP v4 compatibility. We had started relying on GMP 5.x (for usage of mpz_powm_sec), but this is pretty painful on RHEL-esque targets, which still use GMP 4.x. In the mean time while we're still supporting this, it's easier to just fallback to mpz_powm when _sec is unavailable, and emit a WARNING for using the primitive. This also installs a header, HsIntegerGmp.h, which clients could use for a fallback. As a side note, this will probably also help Debian oldstable users who might have outdated GMP versions (which I believe is the cause for #8666.) Reviewed-by: Herbert Valerio Riedel Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 22:21:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 22:21:54 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.b884d760ebcb9bac66d4c7a62f4b65bb@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): After looking at this, the reason for this is probably because the in-tree GMP is a bit broken, and doesn't compile correctly dynamically. In the mean time, I have pushed a patch to restore compatibility with (much) older GMP versions, meaning as long as your Debian Squeeze machines have `libgmp-dev` installed, everything should be fine. I'd appreciate it if someone could test this on HEAD (or the upcoming RC2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 22:22:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 22:22:33 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.7c1a58b933c54d22bd143f2808f36a79@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by thoughtpolice): (I mean, test it on Debian - I have confirmed that RHEL can use gmp 4 from the regular repositories, and GHC compiles without issue). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 26 22:40:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Feb 2014 22:40:48 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.927197a5c766f7421205224c4c8d86b0@haskell.org> #7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Comment (by erikd): I'd forgotten all about this ticket. GHC now builds for me so I need to get back onto it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 00:56:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 00:56:43 -0000 Subject: [GHC] #8828: allow fully applied type families in instance heads Message-ID: <045.6152be3035980bd31e93fc1579e85689@haskell.org> #8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ?Show (TX Int)? }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 09:42:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 09:42:38 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.7782f4aae08a3e5f66f8175f67c4db44@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by simonmar): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 11:35:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 11:35:28 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.79aa8eaf84f7d2f38ffec497501c77ce@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by bernalex): Hi guys. I'm a complete newbie to GHC, and even Haskell still, so keep that in mind. The best (and certainly most fun) way for me to familiarise myself with the GHC code base was to dive right in. So I was hacking on base for fun and encountered an odd bug, and christiaanb in #ghc pointed me here. Replying to [comment:13 nomeata]: > I occasionally have that as well; right now in `library/base`: > {{{ > HC [stage 1] libraries/base/dist-install/build/Control/Applicative.o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140129 for x86_64-unknown-linux): > tcIfaceGlobal (local): not found: > base:Control.Applicative.$fApplicativeWrappedMonad{v ri} > [(0c7, Identifier ?base:Control.Applicative.<*>{v 0c7}?), > (0c8, Identifier ?base:Control.Applicative.pure{v 0c8}?), > (0c9, Class ?base:Control.Applicative.Alternative{tc 0c9}?), > ... > }}} > > Thorough cleaning helps. Sorry, no further clues. I get this: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140225 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: base:Control.Applicative.$fApplicativeWrappedMonad{v ri} [(0c7, Identifier ?base:Control.Applicative.<*>{v 0c7}?), (0c8, Identifier ?base:Control.Applicative.pure{v 0c8}?), (0c9, Class ?base:Control.Applicative.Alternative{tc 0c9}?), (2y, Class ?base:Control.Applicative.Applicative{tc 2y}?), (rE, Data constructor ?base:Control.Applicative.D:Alternative{d rE}?), (r1J, Coercion axiom ?base:Control.Applicative.NTCo:ZipList{tc r1J}?), (r2K, Coercion axiom ?base:Control.Applicative.NTCo:Const{tc r2K}?), (r3c, Coercion axiom ?base:Control.Applicative.NTCo:WrappedMonad{tc r3c}?), (r3i, Coercion axiom ?base:Control.Applicative.NTCo:WrappedArrow{tc r3i}?), (r3T, Data constructor ?base:Control.Applicative.D:Applicative{d r3T}?), (r45, Identifier ?base:Control.Applicative.$p1Applicative{v r45}?), (r46, Identifier ?base:Control.Applicative.$p1Alternative{v r46}?), (r4a, Identifier ?base:Control.Applicative.getZipList{v r4a}?), (r4b, Data constructor ?base:Control.Applicative.ZipList{d r4b}?), (r4c, Type constructor ?base:Control.Applicative.ZipList{tc r4c}?), (r4d, Identifier ?base:Control.Applicative.unwrapMonad{v r4d}?), (r4e, Data constructor ?base:Control.Applicative.WrapMonad{d r4e}?), (r4f, Type constructor ?base:Control.Applicative.WrappedMonad{tc r4f}?), (r4g, Identifier ?base:Control.Applicative.unwrapArrow{v r4g}?), (r4h, Data constructor ?base:Control.Applicative.WrapArrow{d r4h}?), (r4i, Type constructor ?base:Control.Applicative.WrappedArrow{tc r4i}?), (r4j, Identifier ?base:Control.Applicative.getConst{v r4j}?), (r4k, Data constructor ?base:Control.Applicative.Const{d r4k}?), (r4l, Type constructor ?base:Control.Applicative.Const{tc r4l}?), (r4m, Identifier ?base:Control.Applicative.<*{v r4m}?), (r4n, Identifier ?base:Control.Applicative.*>{v r4n}?), (r4o, Identifier ?base:Control.Applicative.some{v r4o}?), (r4p, Identifier ?base:Control.Applicative.many{v r4p}?), (r4q, Identifier ?base:Control.Applicative.empty{v r4q}?), (r4r, Identifier ?base:Control.Applicative.<|>{v r4r}?), (r1BR, Identifier ?base:Control.Applicative.Const{v r1BR}?), (r1Cf, Identifier ?base:Control.Applicative.WrapArrow{v r1Cf}?), (r1CD, Identifier ?base:Control.Applicative.WrapMonad{v r1CD}?), (r1CT, Identifier ?base:Control.Applicative.ZipList{v r1CT}?), (r1Da, Identifier ?base:Control.Applicative.$dm*>{v r1Da}?), (r1DL, Identifier ?base:Control.Applicative.$dm<*{v r1DL}?), (r1DN, Identifier ?base:Control.Applicative.D:Applicative{v r1DN}?), (r1DO, Identifier ?base:Control.Applicative.$dmsome{v r1DO}?), (r1EP, Identifier ?base:Control.Applicative.$dmmany{v r1EP}?), (r1ER, Identifier ?base:Control.Applicative.D:Alternative{v r1ER}?)] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/base/dist-install/build/Control/Applicative.o] Error 1 make: *** [all_libraries/base] Error 2 }}} It's been consistent for me. What I've been doing is applying patches to base, and then I want to rebuild it as cheaply as possible. Reading the build guides I came up with several things to try. I have tried the following (some of them might be entirely equivalent): {{{ make # in the base directory make all_libraries/base make FAST=YES }}} Cleaning does, as mentioned, help. Failing to derive a logical solution, I went with the "engineer's approach" and simply did: {{{ rm libraries/base/dist-install/build/Control/Applicative.* rm libraries/base/dist-install/build/Data/List_* -R rm libraries/base/dist-install/build/Prelude* -R make FAST=YES }}} This was an attempt at just throwing out offenders and observing the results. This seemed to work nicely (i.e. make FAST=YES succeeded without errors), however make install failed with the same error as above. A regular make clean && make && make install worked nicely though. I would be happy to assist in trying to arrive at a predictable method of reproducing this problem. Some information on what I am using: {{{ ghc 018676c7f883886b388652c913c99a10d2591b0b base eea1b6f5fe254b249acc618ef5a82c3e52a27f8c (+ 2 of my patches -- rebuilding failed for both) Linux hackintosh 3.13.3-gentoo #10 SMP Sat Feb 15 11:17:38 CET 2014 x86_64 Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz GenuineIntel GNU/Linux automake 1.13.4 autoconf-2.69 }}} If other information would be pertinent, please let me know and I will post it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 12:23:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 12:23:17 -0000 Subject: [GHC] #7097: linker fails to load package with binding to foreign library In-Reply-To: <042.8652c19ed572825fd749b02b3e025d62@haskell.org> References: <042.8652c19ed572825fd749b02b3e025d62@haskell.org> Message-ID: <057.5bfc33ba1ee009383e0838f8e6d6e4a8@haskell.org> #7097: linker fails to load package with binding to foreign library -----------------------------------+------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #2283 #3242 #1883 -----------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) Comment: Is this now fixed with the Windows linker fixes in 7.8.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 12:50:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 12:50:12 -0000 Subject: [GHC] #8829: GHC HEAD/7.8 fails to build on Solaris 10 Message-ID: <046.7dcb5f6b84381ef10d096b9ada5756ce@haskell.org> #8829: GHC HEAD/7.8 fails to build on Solaris 10 ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- Just to record this issue for further reference. Solaris 10 provides GCC 3.4.3 as a free compiler. Unfortunately compilation of GHC with this compiler fails with: {{{ gmake -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc- Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc- Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc- Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc- DCOMPILING_RTS -optc-DNOSMP -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno- strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc- fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_thr_debug\" -static -optc-DTHREADED_RTS -optc-DDEBUG -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/sm/GC.c -o rts/dist/build/sm/GC.thr_debug_o /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax gmake[1]: *** [rts/dist/build/sm/GC.thr_debug_o] Error 1 gmake: *** [all] Error 2 }}} the problem analysis so far reveals that the problematic assembler code looks: {{{ 17826 .byte 0x3 17827 .word %r_tls_dtpoff32(gct) 17828 .byte 0xe0 }}} which seems to be kind of wrong. When I tested this with Solaris 11.1 GCC 4.5.2 I've not able to reproduce this error so I guess this is kind of miscompilation in GCC 3.4.3. Actually this is Solaris 10 update 11 distributed GCC: {{{ $ gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with- ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable- shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) }}} so that may serve as kind of known issue on sparc/solaris 10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 13:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 13:34:36 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.8a7971379950e2033e3b310217d1e9bc@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by simonpj): Is it possible that you could reproduce your steps, in a fresh repo, and reproduce the crash. That is, can you give us a recipe for making it happen? That would be ''really'' useful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 13:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 13:59:39 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.da90ed37b1b06a51bb60152b7a90a7c6@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by simonpj): Well nailed! We need the cloning because when we float bindings out we might widen the scope of its binders, and we don't want to accidentally capture an un- related occurrence. Originally we only floated let-bindings, which bind only Ids, and so the substitution substituted only for Ids. But now we flaot case-expressions too, and they can bind type variables. Once the substitution binds type variables it must be applied to many more things (e.g. the types of other binders) which is not done at all at the moment. So your diagnosis is right but the fix isn't a one-liner. I'll work on it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 14:54:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 14:54:18 -0000 Subject: [GHC] #8374: `tcIfaceGlobal (local): not found` while compiling In-Reply-To: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> References: <046.ccbc5bfedc9c77196800e445ac95da44@haskell.org> Message-ID: <061.b26f18e1f14451b0ac65d8ed3711557f@haskell.org> #8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------------------+--------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+--------------------------- Comment (by bernalex): {{{ cd git git clone git://github.com/ghc/ghc.git ghc2 cd ghc2 ./sync-all pull ./sync-all get ./perl boot ./configure --prefix=/home/alexander/tmp/ghc make -j5 cd libraries/base/ git am ~/git/ghc/libraries/base/0001-Implement-nand-nor-nany-and-nall-in- Data.List.patch make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:24:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:24:44 -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.5f283550256772f35228824fdff34af3@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Summarising the behaviour. If you say `:load Foo` in GHCi * `Foo` was compiled with `-dynamic`: loads `Foo.dyn_o` * `Foo` was compiled without any dynamic flag: does not find object files, so interprets. * `Foo` was compiled with `-dynamic-too`: fails as above. Not a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:37:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:37:20 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.0801a5a6898d145e39fbf56b426526ee@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by Simon Marlow ): In [changeset:"b1ddec1e6d4695d71d38b59db26829d71ad784e1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b1ddec1e6d4695d71d38b59db26829d71ad784e1" Fix a bug in codegen for non-updatable selector thunks (#8817) To evaluate most non-updatable thunks, we can jump directly to the entry code if we know what it is. But not for a selector thunk: these might be updated by the garbage collector, so we have to enter the closure with an indirect jump through its info pointer. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:37:21 -0000 Subject: [GHC] #8254: confusing comment on allocate() In-Reply-To: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> References: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> Message-ID: <062.17275ee3f3367cb4af151e46032163b4@haskell.org> #8254: confusing comment on allocate() --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"68c0d8689dd93cb0ce74a288e82f2ed997c31acc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="68c0d8689dd93cb0ce74a288e82f2ed997c31acc" fix comment on allocate() (#8254) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:37:21 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:37:21 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.a3a29d8b9223e4d753d81ccd1764f896@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Simon Marlow ): In [changeset:"af6746fb6b5adb5ba5be6e0f647c4ebe767ce084/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="af6746fb6b5adb5ba5be6e0f647c4ebe767ce084" Add hs_thread_done() (#8124) See documentation for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:38:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:38:02 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.506ed93da25a9adec66d6954b57a9969@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Why does Safe Haskell require that the constructors of `List` should be in scope in module B? Point 3 of `Note [Coercible Instances]` in `TcInteract` doesn't explain. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:41:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:41:33 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.0d0ca11a8cfd4bb31927c6b8de0fa0c4@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by simonmar): * status: new => merge Comment: I fixed the problem with `-A16k`, which is actually a nasty codegen bug. I suspect the problem with `-A4k` is more benign and only occurs with very tiny `-A` values, and I think it's been around for a while. So merge this patch, then leave the ticket open with a lower prio for the -A4k fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:42:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:42:57 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.40cd597256deaf18b79d19c8750053bb@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): > Why do we need this? In order to forestall any possible abstraction breaking. I don't buy this. Why are inferred '''roles''' different from inferred '''kinds'''? What bad things would happen if we simply abandoned the restriction that the constructors of the type must be in scope to do allow coercion from `(T Int)` to `(T Age)`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:43:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:43:33 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.48d83f9e2575071775d43f7a8e867be6@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by thoughtpolice): For the record, unless there are any other suggestions, I'll likely take Joachim's suggestion of putting this in `Data.Coerce`. Any other suggestions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:45:36 -0000 Subject: [GHC] #8254: confusing comment on allocate() In-Reply-To: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> References: <047.f2bfb1d82a66bdcef27cbf1185aab323@haskell.org> Message-ID: <062.a942e669f0d399fd74aa828bd902ada0@haskell.org> #8254: confusing comment on allocate() --------------------------------------+------------------------------------ Reporter: rwbarton | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Documentation bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:48:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:48:06 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.1fa0488844e2c1738f3163c404ef0230@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:49:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:49:41 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.9888c7b2c9f204c451f84781b732c74e@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonmar): * status: new => merge * version: 7.6.3 => 7.8.1-rc1 * milestone: 7.8.2 => 7.8.1 Comment: Let's get this into 7.8.1 RC2. I don't think it will break anything that isn't using it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:50:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:50:53 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.dedc01a47e4df9ef2171a4cef4c11001@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): From the manual, describing the guarantees of Safe Haskell: Module boundary control ? Haskell code compiled using the safe language is guaranteed to only access symbols that are publicly available to it through other modules export lists. An important part of this is that safe compiled code is not able to examine or create data values using data constructors that it cannot import. If a module M establishes some invariants through careful use of its export list then code compiled using the safe language that imports M is guaranteed to respect those invariants. Because of this, Template Haskell and !GeneralizedNewtypeDeriving are disabled in the safe language as they can be used to violate this property. Without the check to make sure that all relevant constructors are in scope, the above property would be false. Truth be told, my proposal above also violates this property, but in a more principled way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:52:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:52:56 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.c110b7f4daad4a8bb063295571de3970@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): From the manual, describing the guarantees of Safe Haskell: Module boundary control ? Haskell code compiled using the safe language is guaranteed to only access symbols that are publicly available to it through other modules export lists. An important part of this is that safe compiled code is not able to examine or create data values using data constructors that it cannot import. If a module M establishes some invariants through careful use of its export list then code compiled using the safe language that imports M is guaranteed to respect those invariants. Because of this, Template Haskell and !GeneralizedNewtypeDeriving are disabled in the safe language as they can be used to violate this property. Without the check to make sure that all relevant constructors are in scope, the above property would be false. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 15:56:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 15:56:19 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.8a4dda0f969ad54c3cf4cae5aae556a0@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): OK, but what does "access the symbols" mean, exactly? The kind of a type constructor may change if you change its implementation; and similarly its roles. I think it should be fine to coerce `T Age` to `T Int`, even if T's constructors are not visible, unless T's author declares T's role to be nominal. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 17:37:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 17:37:41 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows Message-ID: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows ----------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- Loading package gnutls-0.1.5 ... ghc.exe: internal error: Misaligned section: 18206e5b (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Only occurs when loading the module in as part of a build involving TH. A non-TH-using program using this library links successfully. I have installed a gnutls built for Windows, from http://josefsson.org/gnutls4win/. Different versions have different section offsets, but all the versions I've tried fail like this. I've also gotten the same error linking gnuidn, instead of gnutls, with gnuidn from ftp://ftp.gnu.org/gnu/libidn/libidn-1.28-win32.zip This makes me think this may be a general ghci on windows bug, rather than a misbuilt library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 18:34:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 18:34:14 -0000 Subject: [GHC] #6138: GHCI Startup Crash with HP 2012.2.0.0 on 64bit OS X 10.6 In-Reply-To: <050.512da14a2ce36c2480bfd514b3fa3a38@haskell.org> References: <050.512da14a2ce36c2480bfd514b3fa3a38@haskell.org> Message-ID: <065.4f7e2972a0ae5e7308d39313d0820726@haskell.org> #6138: GHCI Startup Crash with HP 2012.2.0.0 on 64bit OS X 10.6 -----------------------------------+---------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+---------------------------------- Changes (by CornedBee): * cc: sebastian.redl@?, simonmar (added) * failure: None/Unknown => GHCi crash * status: closed => new * resolution: wontfix => * version: 7.4.1 => 7.6.1 Comment: So I installed GHC 7.6.3 (which is missing from the version field below, btw) and XCode 4.2 (the newest thing available for OSX 10.6.8), and I'm observing the same intermittent crash. 64-bit version. So either 7.6 needs an even newer XCode than 7.4 (why?) and the website needs another update, or the issue is not with an old XCode; instead it's with 10.6 in general. Which would be a real pity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 20:07:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 20:07:31 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.0a39fe3cec1feefc1cd18c91c040a6ba@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): I?m still on holidays with bad connection, otherwise I?d do it. `Data.Coerce` sounds good, which should be the haddock home module. `GHC.Exts` should then only re-export that module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 20:54:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 20:54:22 -0000 Subject: [GHC] #8826: Allow more coercions in Safe Haskell In-Reply-To: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> References: <047.5c2eeb13a41e01da9bb6e46c88e0f15c@haskell.org> Message-ID: <062.320d563a46445cb353d634f633ca7dad@haskell.org> #8826: Allow more coercions in Safe Haskell -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 27 20:54:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Feb 2014 20:54:42 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.df7af5a14d3e0d7662fc277ff583954c@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * cc: mail@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 05:20:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 05:20:32 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.cb7edc49844b49416d6e3be84eb13618@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by luite): * priority: highest => normal Comment: Thanks, this appears to have fixed our GHCJS segfaults! Since the other problem is easily avoided, I set it to normal priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 05:21:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 05:21:26 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.e7b2408d97e7d05e901dd77b0f3421ea@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by luite): * priority: normal => highest Comment: Oops, let's leave at highest until merged -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 08:10:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 08:10:07 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.3666c3f8db8f8d9db40b188088031dcb@haskell.org> #7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"67029f200c5512f8ba5b9b7c25a5d1131422ef8e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="67029f200c5512f8ba5b9b7c25a5d1131422ef8e" PPC: Fix loads of PIC data with > 16 bit offsets (#7830). Loads should now handle up to 32 bit offsets. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 08:12:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 08:12:07 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.4772a42ef750061f6a2e7a5ad2bbcd92@haskell.org> #7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 08:48:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 08:48:34 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.dd68f4fd5b90e76c3dc2bf21863928ea@haskell.org> #7830: Error: operand out of range ------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+--------------------------- Changes (by hvr): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 10:01:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 10:01:55 -0000 Subject: [GHC] #8707: Kind inference fails in data instance definition In-Reply-To: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> References: <047.42701da74b266d5a65dd7046a49e3572@haskell.org> Message-ID: <062.a90550c1cae8b4bc47d7666eab2b27c2@haskell.org> #8707: Kind inference fails in data instance definition -------------------------------------+------------------------------------ Reporter: goldfire | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jstolarek): > 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. Code responsible for this difference is here [[GhcFile(compiler/types/TypeRep.lhs#L711)]] in the function `pprTcApp`: {{{ | Just dc <- isPromotedDataCon_maybe tc , let dc_tc = dataConTyCon dc , isTupleTyCon dc_tc , let arity = tyConArity dc_tc -- E.g. 3 for (,,) k1 k2 k3 t1 t2 t3 ty_args = drop arity tys -- Drop the kind args , ty_args `lengthIs` arity -- Result is saturated = pprPromotionQuote tc <> (tupleParens (tupleTyConSort dc_tc) $ sep (punctuate comma (map (pp TopPrec) tys))) }}} The only question is how we want the arguments printed? GHC 7.6 prints them like this: {{{ Data constructor `SFalse' returns type `SingDF Bool k ('(,) Bool (k -> *) 'False (Ctor k))' instead of an instance of its parent type `SingDF Bool Bool a' }}} GHC HEAD prints tuple constructors in the standard notation (not prefix as seen in GHC 7.6 output): {{{ Data constructor ?SFalse? returns type ?SingDF Bool k '(Bool, k -> *, 'False, Ctor k)? instead of an instance of its parent type ?SingDF Bool Bool a? }}} But printing kinds as part of a tuple is misleading. Any suggestions how should the output look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 16:56:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 16:56:08 -0000 Subject: [GHC] #8791: Use new primitive bitwise operations for Int# in Data.Bits In-Reply-To: <042.dafef0a3988131827ed64c838619782e@haskell.org> References: <042.dafef0a3988131827ed64c838619782e@haskell.org> Message-ID: <057.054c6f616ef3ab81ec56983d0a62f4e2@haskell.org> #8791: Use new primitive bitwise operations for Int# in Data.Bits -------------------------------+------------------------------------------- Reporter: cdk | Owner: cdk Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #7689 Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: Merged via [c17729feb11b7992089a8cac540dd999b76557bc/base] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 17:42:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 17:42:43 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.1c970c1097dea4212f754f5a74463137@haskell.org> #7830: Error: operand out of range ------------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+----------------------------- Changes (by thoughtpolice): * version: 7.7 => 7.8.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 18:04:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 18:04:28 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.78758054b4d381772924e45368ba432c@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 18:07:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 18:07:50 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.12d2a3290dd9a600a147be8159dd8f75@haskell.org> #5013: sporadic failures during compilation under solaris ----------------------------------+----------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+----------------------------- Changes (by thoughtpolice): * version: 7.9 => 7.8.1-rc1 * milestone: => 7.8.1 Comment: This patch looks safe for other architectures (as the retry will only happen under `EINTR` obviously), so I'm merging it for 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 18:25:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 18:25:40 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.61f8250fc6cea305c14ce9cbd458117f@haskell.org> #5013: sporadic failures during compilation under solaris -----------------------------------+----------------------------- Reporter: maeder | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------- Changes (by hvr): * component: Compiler => libraries/unix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 19:06:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 19:06:48 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.33fb87778460b5564564aa08af4840d9@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ekmett): FWIW- The committee is in favor of adding the `Generic`, `Generic1`, `Data` and `Typeable` instances along with `Num` for `Sum` and `Product`. Do we want to try to pester Austin at the 11th hour to add them to the 7.8 release candidate or hold off a year for 7.10? The former has the benefit of, well, being a year sooner, but it may be that that ship has already sailed. Moreover, it'd means you can't write code that needs those instances and which works with both the 7.8.1-release candidates and the final release. On the other hand, once we have 7.8.1 the release candidates will have done their job and will be a non-issue. At this point I defer to Austin about the viability of packaging it up now or if we should wait. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 19:17:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 19:17:23 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.0d31b5e0010fdfebb491c7147b4c7ada@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by thoughtpolice): After reviewing with Edward, these changes are so trivial and obvious that I'll push them in with a small set of patches today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 19:38:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 19:38:55 -0000 Subject: [GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error In-Reply-To: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> References: <051.cb0e35c535a96f63b79be96a3b393757@haskell.org> Message-ID: <066.d28dfbc247e28dd4457a1aed7c93a74f@haskell.org> #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error -------------------------------------+---------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Comment (by CoreyOConnor): Thanks for the investigation! Is there a situation where this would cause a runtime crash? I ran across this investigating a crash in the yi editor application. According to valgrind the GC performs an invalid write: writes into a block not allocated AFAICT. If that is too much to conjecture then no worries. I'm still breaking the crash down into a smaller test case. This just fell out of that process. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 20:52:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 20:52:14 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.ddac33003eb65f3e6592d01e7acc8e2e@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * version: 7.6.3 => 7.8.1-rc1 * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:00:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:00:15 -0000 Subject: [GHC] #8831: Cannot use Template Haskell splice in ghci Message-ID: <047.1688ea3628125d840e5d96b182466527@haskell.org> #8831: Cannot use Template Haskell splice in ghci ------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have this module: {{{ {-# LANGUAGE TemplateHaskell #-} module A where foo = [| 3 |] }}} Now, I do this in ghci: {{{ > :seti -XTemplateHaskell > :load A.hs [1 of 1] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A. > $foo Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.4.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. unknown package: main }}} The problem is the last line, failing to find the `main` package. I can reproduce this issue in 7.8rc1 and in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:42:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:42:32 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.4fb4405e90c86fb4427c858e3f237679@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Austin Seipp ): In [changeset:"f932b79948f0f8e2ac354cdcaea21c5b7c59a27a/base"]: {{{ #!CommitTicketReference repository="base" revision="f932b79948f0f8e2ac354cdcaea21c5b7c59a27a" Create Data.Coerce (#8745) Data.Coerce is a Trustworthy module which safely exports both `Coercible` and `coerce` for use by users, as it can now be considered safe under role checking. See the ticket for details. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:42:33 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.763730e2ea1803f901eb8203f42eb674@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Austin Seipp ): In [changeset:"1a9abe7a1a3c77a028cf23640368cb45527d5834/base"]: {{{ #!CommitTicketReference repository="base" revision="1a9abe7a1a3c77a028cf23640368cb45527d5834" Add some instances for Monoid/Applicative (#8797) As noted in the ticket, there's no particular reason why there aren't Generic, Typeable, and Data instances for the types in the Monoid/Applicative modules. Furthermore, Product and Sum should also have Num instances as well as Edward noted. Aside from that, this patch also changes the dependency chain slightly - it moves the Monoid Proxy instance into Data.Monoid and out of Data.Proxy. Why? Cycles (of course). Monoid depends on Typeable. Typeable uses Proxy. Proxy uses Monoid. Boom. Luckily, Proxy only depends on Monoid outside of the GHC namespace, so the fix is easy and clean. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:44:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:44:02 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.1bc4c4c8f875790d9450875e7547c967@haskell.org> #5013: sporadic failures during compilation under solaris -----------------------------------+----------------------------- Reporter: maeder | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------- Changes (by thoughtpolice): * status: patch => merge Comment: This is merged in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:44:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:44:12 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.f3bdeec6a80a9c546e6267e7b8b00da7@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | 7.8.1-rc1 Operating System: Unknown/Multiple | Keywords: Safe Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple should_fail/TcCoercibleFailSafe | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 21:44:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 21:44:29 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.7af4f0873e199ccfeab7fe7869a90c70@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: merge request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 22:05:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 22:05:52 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.86db83f92acfda72ea52c11c62f353e3@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: merge request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by jcristovao): I'm _very_ glad that this is being pushed to 7.8. Really good news. For my particular use case these are good enough, but if I might push the envelop, why stop here? I'm certain some modules are more dificult than others, due to dependency cycles, but (and withouth checking for that, just from a quick round up), why not include these: Control.Arrow: Kleisli, ArrowMonad Data.Fixed: Fixed, E0, E1, ... Data.Unique: Unique Data.Traversable: StateL, StateR, Id Data.Ord: Down System.Timeout: Timeout Also for Generic, Generic1, Data. If easy enough (i.e., no hard dependencies), it might be useful to someone else. Just a though, Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 22:12:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 22:12:15 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.9185678f09fb4ed3fafd8bf19ffbb660@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: merge request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by thoughtpolice): We should open a separate ticket for these I think. Edward I'm sure will agree that we need to look out for adding more sensible instances for the types in base (we always seem to forget some, somewhere). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:33:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:33:22 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.771ecf6c5d9ed7f0f357ee30b8b71ae7@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Simon?s commit broke the CI builds, see: https://s3.amazonaws.com/archive.travis-ci.org/jobs/19838358/log.txt {{{ =====> T8124(normal) 2080 of 3905 [0, 0, 0] Compile failed (status 256) errors were: : does not exist: T8124_c.c *** unexpected failure for T8124(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:40:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:40:39 -0000 Subject: [GHC] #5013: sporadic failures during compilation under solaris In-Reply-To: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> References: <045.60b676bf3753dc6058e807ea654417dd@haskell.org> Message-ID: <060.7bb27f3073649df78c38d605e5de054a@haskell.org> #5013: sporadic failures during compilation under solaris -----------------------------------+----------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:40:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:40:44 -0000 Subject: [GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem In-Reply-To: <042.41e003931db44554a93be772501d4d70@haskell.org> References: <042.41e003931db44554a93be772501d4d70@haskell.org> Message-ID: <057.4e03f1e6cebb6fd7279c3f6f990684e9@haskell.org> #8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: AlainODea Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: libraries/unix | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:40:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:40:59 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.b9f6d8769e7c0429490ef576d487cfa7@haskell.org> #7830: Error: operand out of range ------------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------------+----------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:41:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:41:41 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.a49f91ee100e3c61d8babcbc9b5583be@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by thoughtpolice): Merged in 7.8 for RC2. I'm probably going to go ahead and cut RC2 - it seems like a missing file was simply not committed, not a huge error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:41:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:41:56 -0000 Subject: [GHC] #8745: GeneralizedNewtypeDeriving is still not Safe In-Reply-To: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> References: <047.6b342ec00b39c44825c380ed2e3995ab@haskell.org> Message-ID: <062.bd6f69bf46ebc95cf405a129d905c781@haskell.org> #8745: GeneralizedNewtypeDeriving is still not Safe -------------------------------------------------+------------------------- Reporter: goldfire | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 7.8.1-rc1 Type of failure: None/Unknown | Keywords: Safe Test Case: | Architecture: should_fail/TcCoercibleFailSafe | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:42:08 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:42:08 -0000 Subject: [GHC] #8797: Generics instances for monoid and applicative newtypes In-Reply-To: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> References: <049.92ef4fcc9c50ed7a1fbf0c9bc1dc5679@haskell.org> Message-ID: <064.a40bfc226406f6dc8eeb66eedbcdf721@haskell.org> #8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc1 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:42:33 -0000 Subject: [GHC] #8817: segmentation fault in 7.8 RC1 In-Reply-To: <049.587f18ac177eee33d831b7f26473022c@haskell.org> References: <049.587f18ac177eee33d831b7f26473022c@haskell.org> Message-ID: <064.c9c405b6f064ccfc3e4e44a31f5aace4@haskell.org> #8817: segmentation fault in 7.8 RC1 -------------------------------------+---------------------------------- Reporter: hamishmack | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged in 7.8 for RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 28 23:43:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Feb 2014 23:43:04 -0000 Subject: [GHC] #8124: Possible leaks when using foreign export. In-Reply-To: <047.b014202ab89a2952c4754390bef7916d@haskell.org> References: <047.b014202ab89a2952c4754390bef7916d@haskell.org> Message-ID: <062.50693d7828ff77e38fe2c4e16ce34d64@haskell.org> #8124: Possible leaks when using foreign export. --------------------------------------------+------------------------------ Reporter: augustss | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler