From trac at galois.com Sun Jun 1 04:43:07 2008 From: trac at galois.com (GHC) Date: Sun Jun 1 04:35:53 2008 Subject: [GHC] #2326: Make configure check sockaddr.sa_len Message-ID: <044.969b2b3410986b0157b91f1ec2efd379@localhost> #2326: Make configure check sockaddr.sa_len ------------------------+--------------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- My previous patch attached in Ticket#2103 uses "#if defined(netbsd_TARGETOS)", so does not care other systems that have member ''s*_len'' (length of ''struct sockaddr_*'') of ''struct sockaddr_*''. This one check if ''struct sockaddr'' has member ''sa_len'' by configure script and uses "#if defined(HAVE_STRUCT_SOCKADDR_SA_LEN)" to determine whether to poke ''s*_len'' or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Sun Jun 1 14:05:11 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jun 1 13:57:46 2008 Subject: test for 6.8.3-may27 Message-ID: <20080601180511.GA1338@scico.botik.ru> About the 6.8.3 candidate of May 27, there remains the question: why it builds DoCon-2.11 considerably slower than ghc-6.8.2 (3 times, as I recall) and needs larger -M memory to build this DoCon ? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Sun Jun 1 14:06:59 2008 From: trac at galois.com (GHC) Date: Sun Jun 1 13:59:47 2008 Subject: [GHC] #2327: -O flag produces faulty code Message-ID: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> #2327: -O flag produces faulty code -----------------------------+---------------------------------------------- Reporter: orenbenkiki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: Optimizer -O | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- The -O flag generates incorrect code in both 6.8.2 and 6.9. I tested it myself on 6.8.2 - The -O flag causes the program to enter a 100% CPU endless loop Heffalump also tested it on 6.9 - The -O flag causes it to segfault Attached is a tgz file containing the code (and the input). ghc --make -o obk Main.hs ; obk -> works ghc --make -o obk -O Main.hs ; obk -> fails -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 1 14:13:39 2008 From: trac at galois.com (GHC) Date: Sun Jun 1 14:06:25 2008 Subject: [GHC] #2327: -O flag produces faulty code In-Reply-To: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> References: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> Message-ID: <059.4068232c20c0b192d5d3584d5910175a@localhost> #2327: -O flag produces faulty code -----------------------------+---------------------------------------------- Reporter: orenbenkiki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: Optimizer -O | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by ganesh): I (Heffalump) only tried with 6.9.20080316, by the way, so it may yet be fixed more recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 04:47:27 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 04:40:12 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.8ac83eb3502b2f576444eca6fb29c387@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: igloo => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 04:51:55 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 04:44:37 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.6f2650134ef909a61a139e63b95ddcf8@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by simonmar): Using the latest 6.8.3 code with DEBUG on, I get an assertion failure: {{{ /64playpen/simonmar/2231 > ~/nightly-stable/compiler/stage2/ghc-inplace --make Control/Concurrent/Session/Queens.hs [ 1 of 12] Compiling Control.Concurrent.Session.SMonad ( Control/Concurrent/Session/SMonad.hs, Control/Concurrent/Session/SMonad.o ) [ 2 of 12] Compiling Control.Concurrent.Session.Bool ( Control/Concurrent/Session/Bool.hs, Control/Concurrent/Session/Bool.o ) [ 3 of 12] Compiling Control.Concurrent.Session.Number ( Control/Concurrent/Session/Number.hs, Control/Concurrent/Session/Number.o ) [ 4 of 12] Compiling Control.Concurrent.Session.List ( Control/Concurrent/Session/List.hs, Control/Concurrent/Session/List.o ) [ 5 of 12] Compiling Control.Concurrent.Session.SessionType ( Control/Concurrent/Session/SessionType.hs, Control/Concurrent/Session/SessionType.o ) [ 6 of 12] Compiling Control.Concurrent.Session.Runtime ( Control/Concurrent/Session/Runtime.hs, Control/Concurrent/Session/Runtime.o ) ghc-6.8.2.20080601: panic! (the 'impossible' happened) (GHC version 6.8.2.20080601 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Since this might be related to the resulting crash, I'll confer with Simon PJ before debugging further. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 05:19:10 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 05:11:55 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.e59c9b03fcd385114f3dd155992e6567@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I pushed (a slight variant of) 2013.patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 05:35:42 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 05:28:25 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 Message-ID: <046.25be20912976f68417223aab5966cd22@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------+------------------------------ Serge reports that "there remains the question: why GHC 6.8.3 release candidate builds !DoCon-2.11 considerably slower than ghc-6.8.2 (3 times, as I recall) and needs larger -M memory to build this !DoCon". A 3x slow-down wrt 6.8.2 is quite unexpected. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 09:32:25 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 09:25:09 2008 Subject: [GHC] #1818: Code size increase vs. 6.6.1 In-Reply-To: <047.29fbfe8c48a7e251205ebcb2f6270931@localhost> References: <047.29fbfe8c48a7e251205ebcb2f6270931@localhost> Message-ID: <056.822271ec60bd0060cbffa7fa9ae54aa0@localhost> #1818: Code size increase vs. 6.6.1 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: I measured a 5% code size difference between 6.8.2 and 6.8.3, but on recompiling a fresh 6.8.2 tree with exactly the same build options as were used for 6.8.3, the difference disappeared. I suspect something caused by a difference in options, so probably not a 6.6.1->6.8.1 regression, and hence I'll close the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 11:47:17 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 11:39:59 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.ac84005314bffde42f32cbc19fc286e5@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I've fixed the crash: {{{ Mon Jun 2 07:37:26 PDT 2008 Simon Marlow * FIX #2231: add missing stack check when applying a PAP }}} The assertion failure in the type checker is still there and appears to be unrelated. We have no evidence that it is actually causing a problem, `-dcore-lint` still passes, Ian: please merge, then re-assign to Simon and move the ticket to the 6.10 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 12:09:55 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 12:02:37 2008 Subject: [GHC] #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor Message-ID: <042.8ec2e257f7876a94d308884cd219f40a@localhost> #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor -----------------------------------------+---------------------------------- Reporter: bos | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- These all perform a lot of consing, which seems rather undesirable. It would be very nice indeed if they could be rebaked in terms of strict left folds. Unfortunately, all of the collections in question seem only to expose non-strict left folds publicly. {{{ instance (NFData k, NFData a) => NFData (Data.Map.Map k a) where rnf = rnf . Data.Map.toList instance NFData a => NFData (Data.Set.Set a) where rnf = rnf . Data.Set.toList instance NFData a => NFData (Data.Tree.Tree a) where rnf (Data.Tree.Node r f) = rnf r `seq` rnf f instance NFData a => NFData (Data.IntMap.IntMap a) where rnf = rnf . Data.IntMap.toList instance NFData Data.IntSet.IntSet where rnf = rnf . Data.IntSet.toList }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 12:31:21 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 12:24:03 2008 Subject: [GHC] #2330: ghc-pkg should not report duplicate depends Message-ID: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> #2330: ghc-pkg should not report duplicate depends ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ $ ghc-pkg field regex-base-0.72.0.1 depends depends: base-3.0.1.0 array-0.1.0.0 base-3.0.1.0 bytestring-0.9.0.1 }}} Note the `base-3.0.1.0 base-3.0.1.0`. This is clearly silly. It causes problems for Cabal. Although we can easily work around this using nub it'd be better if duplicate depends were never reported or better yet rejected or eliminated at package registration time. (I'm not sure how it ended up this way, I don't think Cabal makes package registration files with duplicate depends) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 12:46:05 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 12:38:47 2008 Subject: [GHC] #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor In-Reply-To: <042.8ec2e257f7876a94d308884cd219f40a@localhost> References: <042.8ec2e257f7876a94d308884cd219f40a@localhost> Message-ID: <051.c2689a274ce13615e68ef3b2eaecb4c0@localhost> #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor -----------------------------------------+---------------------------------- Reporter: bos | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Comment (by ross): All but IntSet are instances of Foldable, and so have Data.Foldable.foldl'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 13:38:56 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 13:31:44 2008 Subject: [GHC] #2306: The (^) operator sometimes uses one (*) more than needed. In-Reply-To: <044.dff49bec25ebc555eb9d893ae67998f1@localhost> References: <044.dff49bec25ebc555eb9d893ae67998f1@localhost> Message-ID: <053.e21e3abb4506e57eddd745c787f49ae9@localhost> #2306: The (^) operator sometimes uses one (*) more than needed. ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Prelude | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: It's now {{{ (^) :: (Num a, Integral b) => a -> b -> a x0 ^ y0 | y0 < 0 = error "Negative exponent" | y0 == 0 = 1 | otherwise = f x0 y0 where -- f : x0 ^ y0 = x ^ y f x y | even y = f (x * x) (y `quot` 2) | y == 1 = x | otherwise = g (x * x) ((y - 1) `quot` 2) x -- g : x0 ^ y0 = (x ^ y) * z g x y z | even y = g (x * x) (y `quot` 2) z | y == 1 = x * z | otherwise = g (x * x) ((y - 1) `quot` 2) (x * z) }}} in the HEAD and 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 13:46:22 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 13:39:06 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 In-Reply-To: <044.b26772684deb839421045da398f72aae@localhost> References: <044.b26772684deb839421045da398f72aae@localhost> Message-ID: <053.294f4f08e3b8a64fbf63fc972d569a58@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 ----------------------+----------------------------------------------------- Reporter: quark | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From pgavin at gmail.com Mon Jun 2 15:37:43 2008 From: pgavin at gmail.com (Peter Gavin) Date: Mon Jun 2 15:30:31 2008 Subject: bug with type families Message-ID: <48444C07.1070308@gmail.com> Hello, I've run into a bug that looks to be the same as the one described here: http://hackage.haskell.org/trac/ghc/ticket/1897 That bug was reported 7 months ago, and I didn't want to modify the bug just to add a "me too" entry to it. Is this a major bug that I shouldn't expect to be fixed for a while? BTW, type families work great otherwise, and I appreciate all the work put in to GHC in general :) Thanks a lot, Peter Gavin From stefan at cs.uu.nl Mon Jun 2 17:04:51 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Mon Jun 2 16:57:33 2008 Subject: bug with type families In-Reply-To: <48444C07.1070308@gmail.com> References: <48444C07.1070308@gmail.com> Message-ID: <4DD3C951-BB7F-4F80-A6D8-989023A5C6F4@cs.uu.nl> Peter, > I've run into a bug that looks to be the same as the one described > here: > > http://hackage.haskell.org/trac/ghc/ticket/1897 It does not seem like a bug, although the type-error message may be a bit confusing as is the fact that GHC happily infers a type for the signature-less function: these are I guess the real issues here. But, apart from that, the contents of a previous discussion seems to apply here: http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html Short version: the type of isValid involves |Depend s| and not |s|. Since |Depend s| does not uniquely determine |s|, it is not possible to resolve which dictionary for Bug to supply for a particular call to isValid. Or---am I overlooking something? Cheers, Stefan From trac at galois.com Mon Jun 2 17:45:48 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 17:38:34 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.eb49cdedd7b1a712bb03bf508983e810@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonpj Type: merge | Status: new Priority: high | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => simonpj * milestone: 6.8.3 => 6.10 branch Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 17:46:47 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 17:39:31 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.228b08547f126cb87b8136b25e955ac8@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 17:48:53 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 17:41:40 2008 Subject: [GHC] #1970: ghci -hide-all-packages gives bad error message In-Reply-To: <046.46e655a12ebdc87b2836ef76c030a7e8@localhost> References: <046.46e655a12ebdc87b2836ef76c030a7e8@localhost> Message-ID: <055.601172b4e3ff7fc578add2f0b8f11532@localhost> #1970: ghci -hide-all-packages gives bad error message ---------------------+------------------------------------------------------ Reporter: dfranke | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 19:08:15 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 19:00:57 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.e911c5180dce50315e2454af81b9e67f@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by Isaac Dupree): There is still an issue here, with HEAD self-compiling its parser/Lexer.{hs|x} generated by `alex` without `-g`. I have it here with 15 minutes of 2GHz CPU time and about 250MB memory used constantly according to `top`, and no evidence of finishing. {{{ ../compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fasm -DDEBUG -H16M '-#include "cutils.h"' -package-name ghc-6.9.20080602 -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi }}} Same with -O as -O0 and -fvia-C instead of -fasm (gcc & friends never start, presumably because GHC hasn't gotten that far)... Oh wait, -fvia-C after 2 minutes GHC CPU, it goes into cc1 (gcc) which is taking all my RAM memory. Hang on a moment, I'll report back when it's done or crashed, I need to free up memory :-) Hmm... it appears some of the settings in my mk/build.mk (-H128M) are being overridden by compiler/Makefile (-H16M). Odd. It's a bit tricky to reproduce, because we obviously we don't expect 6.8 and previous to succeed. I first got a working stage1, then proceeded to modify mk/config.mk{,.in} to delete the `-g` from the `GHC_ALEX_OPTS` line, then removed the file compiler/parser/Lexer.hs (to make sure it would be regenerated with the new settings), then `cd compiler` and `make stage=2`. Obviously simpler test cases could exist, but it's not simple to see how to simplify this instance of GHC getting overwhelmed without wrecking it -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 19:29:55 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 19:22:38 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.0b9e365c50008d4d42efeac968bc53ac@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by Isaac Dupree): update: with my 2 GB RAM and 3 GB swap space, gcc took a long time swapping, but got in a good 2 minutes of CPU time according to `top` (cc1 achieving about 80% of my RAM used at any one time, and between 0 and 50 percent of my 2GHz CPU) before dying due to lack of virtual memory. Therefore, it seems that while there is a moderate performance issue with GHC through STG (2 minutes for a single file?), the assembly is the really difficult part: GCC needs an obscene amount of memory, and GHC's -fasm either needs an obscene or infinite amount of time. But let me check back again... that might have been the optimizations and my cutting corners... {{{ Makefile:1004: LIBRARY is libHSghc.a ../compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fvia-C -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fvia-C -DDEBUG -H16M '-#include "cutils.h"' -package-name ghc-6.9.20080602 -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi Binary: expanding to size: 6144 Binary: expanding to size: 6144 Binary: expanding to size: 6144 Binary: expanding to size: 6144 virtual memory exhausted: Cannot allocate memory <> make: *** [stage2/parser/Lexer.o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 19:45:13 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 19:37:54 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.dfb3f96b3bc06095e60162f9695b4ef0@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by Isaac Dupree): -O0 -fasm succeeded within 3 minutes and 400 MB RAM or so. {{{ ./compiler/stage1/ghc-inplace -no-user-package-conf -H128m -O0 -fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -I../libffi/build/include -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -Iutil -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -O0 -fasm -DDEBUG -H16M '-#include "cutils.h"' -package-name ghc-6.9.20080602 -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi Binary: expanding to size: 6144 Binary: expanding to size: 6144 Binary: expanding to size: 6144 Binary: expanding to size: 6144 <> }}} new summary: -O0 -fasm completely works, though it's slower than ideal. -O0 -fvia-C dies because GCC isn't prepared for how much we're throwing at it. Seems hard for us to fix: lucky we're working on the NCG (though possibly ghc -O would simplify the generated C code enough for GCC to survive, but that'd be IMHO unlikely in this case). (though I wonder if the GCC people know, or should know, that their compiler behaves poorly in these artificial-but-real cases) -O takes way too long (I only thoroughly tested -O with -fasm, so the slow optimizations could be Core, Cmm, anything; and maybe it succeeds in an hour's time, I don't know, would you like me to test on my computer for up to a whole day?). I'm not entirely surprised, but it's still a somewhat serious bug from my point of view. -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 20:04:12 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 19:56:57 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.8acf1798e3a54cde2ac133e654fa5c37@localhost> #1897: Type families: type signature rejected -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Comment (by pgavin): just a note: it seems that the following thread may apply, in case someone else runs into this problem: http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html -- Ticket URL: GHC The Glasgow Haskell Compiler From pgavin at gmail.com Mon Jun 2 20:26:32 2008 From: pgavin at gmail.com (Peter Gavin) Date: Mon Jun 2 20:19:18 2008 Subject: bug with type families In-Reply-To: <4DD3C951-BB7F-4F80-A6D8-989023A5C6F4@cs.uu.nl> References: <48444C07.1070308@gmail.com> <4DD3C951-BB7F-4F80-A6D8-989023A5C6F4@cs.uu.nl> Message-ID: <48448FB8.5030105@gmail.com> Stefan Holdermans wrote: > Peter, > >> I've run into a bug that looks to be the same as the one described here: >> >> http://hackage.haskell.org/trac/ghc/ticket/1897 > > It does not seem like a bug, although the type-error message may be a > bit confusing as is the fact that GHC happily infers a type for the > signature-less function: these are I guess the real issues here. But, > apart from that, the contents of a previous discussion seems to apply here: > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html > > Short version: the type of isValid involves |Depend s| and not |s|. > Since |Depend s| does not uniquely determine |s|, it is not possible to > resolve which dictionary for Bug to supply for a particular call to > isValid. > > Or---am I overlooking something? > No, that makes perfect sense to me now. Thanks. I put up a note on #1897 pointing to that thread, but left it open because the error message needs to be fixed :) Pete From trac at galois.com Mon Jun 2 21:47:31 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 21:40:11 2008 Subject: [GHC] #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns Message-ID: <042.75c5254b7132afeaabac69b43afbc501@localhost> #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns ------------------------+--------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ Prelude> let f (!x) = True :1:6: Illegal bang-pattern (use -fbang-patterns) }}} Since GHC is encouraging the use of -X options, shouldn't this suggest -XBangPatterns? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 2 22:52:20 2008 From: trac at galois.com (GHC) Date: Mon Jun 2 22:45:01 2008 Subject: [GHC] #2332: Can't allocate 4 gigs of RAM Message-ID: <049.b927c02f2fd47c4ea604c4be8f41114f@localhost> #2332: Can't allocate 4 gigs of RAM ----------------------------------+----------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: memory allocation | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------+----------------------------------------- The program at http://hpaste.org/8058 produces a segmentation fault on my machine. I have 8 gigs of RAM, running 64-bit Ubuntu with 64-bit ghc. See http://hpaste.org/8057 for another version of the same problem when using larger sizes. -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Tue Jun 3 03:54:49 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Jun 3 03:47:32 2008 Subject: bug with type families In-Reply-To: <4DD3C951-BB7F-4F80-A6D8-989023A5C6F4@cs.uu.nl> References: <48444C07.1070308@gmail.com> <4DD3C951-BB7F-4F80-A6D8-989023A5C6F4@cs.uu.nl> Message-ID: <3A78AC6E-CA5F-4F41-9FBA-6037E13DAC6E@cse.unsw.edu.au> Stefan Holdermans: > Peter, > >> I've run into a bug that looks to be the same as the one described >> here: >> >> http://hackage.haskell.org/trac/ghc/ticket/1897 > > It does not seem like a bug, although the type-error message may be > a bit confusing as is the fact that GHC happily infers a type for > the signature-less function: these are I guess the real issues here. > But, apart from that, the contents of a previous discussion seems to > apply here: > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041385.html > > Short version: the type of isValid involves |Depend s| and not |s|. > Since |Depend s| does not uniquely determine |s|, it is not possible > to resolve which dictionary for Bug to supply for a particular call > to isValid. > > Or---am I overlooking something? No, what you are saying is exactly right. I'll close the ticket. Manuel From trac at galois.com Tue Jun 3 03:56:45 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 03:49:30 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.ef387e8c2f9be185023bb6e4a0e89216@localhost> #1897: Type families: type signature rejected -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid Comment: This is not a bug, see the discussion in the mailing list URL of the previous comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 05:39:48 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 05:32:31 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.5aeb2a02e14b8d409dbc8c934fb96d84@localhost> #1897: Type families: type signature rejected -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * priority: normal => low * status: closed => reopened * resolution: invalid => Comment: I think we should leave this open, albeit at low priority, because the error message is rather confusing. It's far from obvious how to improve it, but it's a nice example. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 06:07:42 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 06:00:23 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.f7a47d2030e167eb574262a30e3fe0b4@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Changes (by simonmar): * priority: lowest => low * milestone: 6.8.3 => 6.10 branch Comment: This is really a bug in MinGW's readdir(): {{{ #include #include main() { DIR *pdir; struct dirent *pdirent; pdir = opendir("foo"); printf("%x %d\n", pdir, errno); pdirent = readdir(pdir); printf("%x %d\n", pdirent, errno); } }}} yields: {{{ $ ls -ld foo d---------+ 2 simonmar mkgroup-l-d 0 Jun 3 10:19 foo/ $ a.exe 3d2c48 0 0 22 }}} where 22 is EINVAL. We should really be using the native Win32 API instead of MinGW here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 06:07:56 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 06:00:36 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.d605dc18f97410068f54e5175beb008c@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Changes (by simonmar): * difficulty: Easy (1 hr) => Moderate (1 day) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 07:19:02 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 07:11:41 2008 Subject: [GHC] #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns In-Reply-To: <042.75c5254b7132afeaabac69b43afbc501@localhost> References: <042.75c5254b7132afeaabac69b43afbc501@localhost> Message-ID: <051.946fed5a8a3fbbb906c0babbcbd35d5a@localhost> #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns ----------------------+----------------------------------------------------- Reporter: ajd | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: I'll do this in an odd moment. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 10:04:08 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 09:56:46 2008 Subject: [GHC] #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns In-Reply-To: <042.75c5254b7132afeaabac69b43afbc501@localhost> References: <042.75c5254b7132afeaabac69b43afbc501@localhost> Message-ID: <051.e9a52a137395b36718e238e77591098d@localhost> #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns ----------------------+----------------------------------------------------- Reporter: ajd | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Tue Jun 3 14:46:45 BST 2008 simonpj@microsoft.com * Fix Trac #2331 (error message suggestion) }}} Merge iff convenient. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 11:02:50 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 10:55:29 2008 Subject: [GHC] #2333: Emit a warning if an INLINE function is a loop breaker Message-ID: <046.23407b4f66367aefddc60efec387ceb9@localhost> #2333: Emit a warning if an INLINE function is a loop breaker --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- If a function is marked INLINE by the user, but can't be inlined because it is a loop breaker, then it would be good to emit a warning of some kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 11:35:17 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 11:27:55 2008 Subject: [GHC] #2325: Compile-time computations In-Reply-To: <042.ec8f910033c06987836e7597539e54db@localhost> References: <042.ec8f910033c06987836e7597539e54db@localhost> Message-ID: <051.d50f86581477a7c1e979333025d7c80c@localhost> #2325: Compile-time computations --------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: constant folding | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: You have to be a bit careful. It's not always the case that {{{ S# x + S# y = S# (x+y) }}} If the sum is too big the result should be a `J#`. I can think of two ways to do this. * Add a `BuiltInRule` for `plusInteger` in `prelude/PrelRules.lhs`. But that would risk getting out of sync with the implementation in the `integer` package. * Add a RULE for `GHC.Integer.plusInteger` of form {{{ plusInteger (S# x) (S# y) = plusIntegerS x y }}} and add code to `GHC.Integer` to implement `plusIntegerS`. Something like {{{ plusIntegerS :: Int# -> Int# -> Integer plusIntegerS i j = case addIntC# i j of (# r, c #) -> if c ==# 0# then S# r else plusInteger (toBigS i1) (toBigS i2) }}} Check that `plusIntegerS` will inline when given literals as arguments. And add a `BuiltInRule` for the `addIntC#` primop. The latter approach seems better, since it'll benefit all users of `addIntC#`, but it has the problem that the host platform and target platform might not have the same beliefs about word size, so it's not obvious how to do the Right Thing in the `BuiltInRule` for `addIntC#`. I'm not sure what a good way to solve that is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 11:35:33 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 11:28:17 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.18f076dec8d96e9aa30d73910285c667@localhost> #1897: Type families: type signature rejected -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Comment (by Isaac Dupree): In this case I'd say something like "GHC can't figure out which class instance you mean by the function's arguments or results' types"... or let's see what an existing error says. {{{ foo :: (Show a, Read a) => Int foo = 1 where x = show (read "xxx") }}} {{{ ambig.hs:4:0: Ambiguous constraint `Show a' At least one of the forall'd type variables mentioned by the constraint must be reachable from the type after the '=>' In the type signature for `foo': foo :: (Show a, Read a) => Int ambig.hs:4:0: Ambiguous constraint `Read a' At least one of the forall'd type variables mentioned by the constraint must be reachable from the type after the '=>' In the type signature for `foo': foo :: (Show a, Read a) => Int }}} Surely we can detect that? If there's something imprecise about "no use of the actual type variable" (outside non-FD class constraints and TF arguments)... See if the type unifies with a copy of itself, and if it doesn't, it shouldn't be allowed? How about {{{ Ambiguous constraint `Depend a' At least one of the forall'd type variables mentioned by the constraint must be reachable from the type after the '=>' In the type signature for `isValid': isValid :: (Bug s) => [Depend s] -> Bool }}} Admittedly "reachable" might confuse people who don't think about what it means. It can be affected by equality constraints, for example. (is `foo :: (a ~ Char, Show a, Read a) => Int; foo = 1` supposed to be rejected by 6.9? It is rejected with the same "Ambiguous constraint" message... and is a useless type constraint, but not an ambiguous one per se) (but `foo :: (a ~ Int) => F a -> F a; foo = id` is perfectly fine) (Also, in this case, leaving `foldM next start ds` without a type-signature inside the type-information-losing `isJust`, ensures that `isJust (foldM next start ds)` has no usable type, for any `ds`.) If we reject the explicit type signature of `foo :: F a -> F a; foo = id` in that thread outright, then I thought we're safe in assuming that this error will only appear in definitions that *do* have an explicit type- signature (it won't be inferred), unlike the typeclass one without its signature?: {{{ foo = 1 where x = show (read "xxx") }}} {{{ ambig.hs:5:24: Ambiguous type variable `a' in the constraints: `Read a' arising from a use of `read' at ambig.hs:5:24-33 `Show a' arising from a use of `show' at ambig.hs:5:18-34 Probable fix: add a type signature that fixes these type variable(s) }}} But I might have been wrong: `isJust (foldM next start ds)` is just as bad as `show . read`: but then, I think that relies on it also having a typeclass constraint that's ambiguous, because you can introduce *that* without an explicit type-signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 11:59:29 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 11:52:10 2008 Subject: [GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" In-Reply-To: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> References: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> Message-ID: <053.4c7f4587253d488b4f4d95f134ad14e4@localhost> #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" -------------------------------------+-------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail188 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by magnushiie): A real-world example of the same error: {{{ -- Specifying -fno-monomorphism-restriction removes the error --{-# OPTIONS_GHC -fno-monomorphism-restriction #-} module ParsecWrap where import Control.Monad.Trans import qualified Text.ParserCombinators.Parsec as P -- these work without type signature many1 f = lift $ P.many1 f oneOf cs = lift $ P.oneOf cs {- :t many1 many1 :: (MonadTrans t) => P.GenParser tok st a -> t (P.GenParser tok st) [a] :t oneOf oneOf :: (MonadTrans t) => [Char] -> t (P.GenParser Char st) Char -} --anyChar :: MonadTrans t => t (P.GenParser Char st) Char anyChar = lift $ P.anyChar {- Without type signature on anyChar, gives: Urk! Inventing strangely-kinded void TyCon: :t{tc a1vc} (* -> *) -> * -> * D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:10: Ambiguous type variable `t' in the constraint: `MonadTrans t' arising from use of `lift' at D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:10-13 Possible cause: the monomorphism restriction applied to the following: anyChar :: forall st. t (P.GenParser Char st) Char (bound at D:\Dev\Test\ParseCpp\src\ParsecWrap.hs:30:0) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction Failed, modules loaded: none. -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 12:16:56 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 12:09:44 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.732aad58fe0783cf9189441bc92922d0@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): Can you test whether this fixes it please, Christian? If it complains that gnu99 doesn't exist then try c99 instead. {{{ diff -rN -u old-ghc/mk/config.mk.in new-ghc/mk/config.mk.in --- old-ghc/mk/config.mk.in 2008-06-03 17:13:20.000000000 +0100 +++ new-ghc/mk/config.mk.in 2008-06-03 17:13:32.000000000 +0100 @@ -964,6 +964,10 @@ SRC_CC_OPTS += -G0 endif +ifeq "$(TargetOS_CPP)" "solaris2" +SRC_CC_OPTS += -std=gnu99 +endif + #----------------------------------------------------------------------------- # GMP Library (version 2.0.x or above) # }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 13:17:11 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 13:10:01 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.f2765c27aeceacd0c4210082f4fdfc86@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): In both cases it fails as follows: {{{ ../compiler/ghc-inplace -optc-O -optc-std=c99 -optc-Wall -optc-W -optc- Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Weak.c -o Weak.o In file included from /usr/include/sys/int_types.h:34, from /usr/include/sys/stdint.h:17, from /usr/include/stdint.h:17, from ../includes/HsFFI.h:31, from ../includes/RtsAPI.h:16, from ../includes/RtsExternal.h:13, from ../includes/Stg.h:177, from ../includes/Rts.h:19, from Weak.c:11:0: /export/local1/mirror/lang/bin/../lib/gcc/i386-pc- solaris2.10/4.2.2/include/sys/feature_tests.h:341:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" In file included from ../includes/Rts.h:190, from Weak.c:11:0: ../includes/Stable.h:48:0: warning: C99 inline functions are not supported; using GNU89 ../includes/Stable.h:48:0: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute gmake[1]: *** [Weak.o] Error 1 gmake: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 13:40:31 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 13:33:09 2008 Subject: [GHC] #2325: Compile-time computations In-Reply-To: <042.ec8f910033c06987836e7597539e54db@localhost> References: <042.ec8f910033c06987836e7597539e54db@localhost> Message-ID: <051.511518297b2e9b7622bc7244e052945c@localhost> #2325: Compile-time computations --------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: constant folding | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Can we do the rule at an earlier point, i.e. {{{ (fromInteger ) + (fromInteger ) ==> (fromInteger ) }}} where we have inferred that the type is `Integer`? Then we don't have to worry about any checking that we don't already do. Re word size differences, we already have that problem when we transform {{{ (fromInteger 3) }}} into {{{ S# 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 14:18:03 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 14:10:42 2008 Subject: [GHC] #2334: panic using type families and type classes Message-ID: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> #2334: panic using type families and type classes ------------------------------+--------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: type families | Testcase: Architecture: x86 | Os: MacOS X ------------------------------+--------------------------------------------- I got a panic while trying to compile some code using type families: ghc-6.9.20080528: panic! (the 'impossible' happened) (GHC version 6.9.20080528 for i386-apple-darwin): urk! lookup local fingerprint I can't post the code that caused that (yet) but when I was trying to distill it down to its essence for a bug report, I got a different panic: ghc-6.9.20080528: panic! (the 'impossible' happened) (GHC version 6.9.20080528 for i386-apple-darwin): Prelude.head: empty list I've attached the code that caused it. I know the code might not be 100% correct, and it's a bit long, but I think it might help some. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 17:01:08 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 16:54:02 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.913e3fd8c46a2b459ce04aa40991ce69@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): OK, how about if you also apply this patch? {{{ diff -rN -u old-ghc/includes/Stg.h new-ghc/includes/Stg.h --- old-ghc/includes/Stg.h 2008-06-03 21:59:00.000000000 +0100 +++ new-ghc/includes/Stg.h 2008-06-03 21:59:00.000000000 +0100 @@ -49,7 +49,7 @@ // And finally, we need _XOPEN_SOURCE in order to get a prototype for // putenv on Linux: -#define _XOPEN_SOURCE +#define _XOPEN_SOURCE 600 #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 3 22:14:48 2008 From: trac at galois.com (GHC) Date: Tue Jun 3 22:07:26 2008 Subject: [GHC] #2335: Haddock's internal GHC version must match the configured GHC version Message-ID: <042.dd7881e9cf460e19411390b51f02530e@localhost> #2335: Haddock's internal GHC version must match the configured GHC version -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: blocker Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- I'm trying to build ghc-6.8.2.20080603 with haddock-2.0.0.0, and I get the above error when the build tries to emit docs for the base package. I'm not really sure how to make progress here. 2.0 is the default version of haddock distributed with Fedora 9. I don't know if haddock 0.8 has the same problem, but unfortunately I can't use it without tremendous bother. Doubly unfortunately, I can't actually tell whether the error is coming from GHC, the system's Haddock, or some other place entirely. What I'm trying to do is prepare the GHC 6.8.3 RPM for Fedora, so that we can roll it in short order once the official release is announced. I'm sorry to be so completely clueless :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 04:35:32 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 04:28:10 2008 Subject: [GHC] #1547: Arity can decrease with -prof In-Reply-To: <044.c0c86188c91ab503a2f98a561709e8de@localhost> References: <044.c0c86188c91ab503a2f98a561709e8de@localhost> Message-ID: <053.ea2dafc9e9b8305038c8dd620ef3a89f@localhost> #1547: Arity can decrease with -prof ---------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Profiling | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: stm package/tests/conc052 | Architecture: Unknown Os: Unknown | ---------------------------------------+------------------------------------ Comment (by simonmar): Update: conc052 is now apparently not failing any more, but this bug hasn't been fixed. I imagine something else has changed such that we don't tickle the bug any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 04:44:59 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 04:37:34 2008 Subject: [GHC] #2325: Compile-time computations In-Reply-To: <042.ec8f910033c06987836e7597539e54db@localhost> References: <042.ec8f910033c06987836e7597539e54db@localhost> Message-ID: <051.10cff6762b9401828cc4095b28afedd4@localhost> #2325: Compile-time computations --------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: constant folding | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonpj): I don't think so. Here's the `Num` instance for `Integer`: {{{ instance Num Integer where fromInteger x = x }}} The argument to `fromInteger` is, well, an `Integer`. So the desugarer converts `3` to `smallInteger 3#`, where `3# :: Int#`. For bigger integers (and the desugarer must make a conservative (wrt word size) estimate of what "big" is), it converts `779988998` into {{{ (smallInteger 7799# `timesInteger` smallInteger 100000#) `plusInteger` smallInteger 88998 }}} or whatever. The function `smallInteger` comes from library `GHC.Integer` in packages `integer`. Hmm. I suppose that we could use the `BuiltInRule` method thus {{{ smallInteger a `plusInteger` smallInteger b = smallInteger (a + #b) if (a +# b) is not "big" }}} using the same conservative estimate for "big" that the desugarer does. (A `BuiltInRule` can have a side condition such as the one above.) To do that we'd have to ensure that `smallInteger` wasn't inlined too early...and we'd sadly miss any opportunities that arose after it was inlined. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 05:27:05 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 05:19:46 2008 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.d6173d810e3ccf44fbf71298e3d709b7@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ---------------------------------------+------------------------------------ Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, math, double | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------+------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Thanks for following this up, Don. But can you be more specific? * Do you have a clear idea about what exactly changes are required? Or are there alternatives to consider? * Can you make concrete proposals? * Or, if it's clear what to do, can you offer a patch? thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 05:36:27 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 05:29:13 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.65fdb3e80c11c4e282b2f01efa8d6bde@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): I've switched to Release Candidate 6.8.2.20080603 (since _XOPEN was missing in 20080527), but it still fails: {{{ == gmake all -r; in /export/local1/home/maeder/ghc-6.8.2.20080603/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -optc-O -optc-std=gnu99 -optc-Wall -optc-W -optc- Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Adjustor.c -o Adjustor.o In file included from /usr/include/sys/int_types.h:34, from /usr/include/sys/stdint.h:17, from /usr/include/stdint.h:17, from ../includes/HsFFI.h:31, from ../includes/RtsAPI.h:16, from ../includes/RtsExternal.h:13, from ../includes/Stg.h:182, from ../includes/Rts.h:19, from Adjustor.c:40:0: /export/local1/mirror/lang/bin/../lib/gcc/i386-pc- solaris2.10/4.2.2/include/sys/feature_tests.h:341:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" In file included from ../includes/Rts.h:190, from Adjustor.c:40:0: ../includes/Stable.h:48:0: warning: C99 inline functions are not supported; using GNU89 ../includes/Stable.h:48:0: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute gmake[1]: *** [Adjustor.o] Error 1 gmake: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 05:50:57 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 05:43:33 2008 Subject: [GHC] #2336: trying to load a module (with GHC API) causes the impossible to happen Message-ID: <044.847e9ff48513cf34a3a9444172b4edf3@localhost> #2336: trying to load a module (with GHC API) causes the impossible to happen ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Here's a minimal test case to reproduce it: {{{ ~/programming% ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + GHC Prelude GHC> s <- newSession (Just "/usr/local/lib/ghc-6.8.2") Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package hpc-0.5.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package Cabal-1.2.3.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package readline-1.0.1.0 ... linking ... done. Loading package ghc-6.8.2 ... linking ... done. Prelude GHC> prelude <- findModule s (mkModuleName "Prelude") Nothing ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): no package state yet: call GHC.setSessionDynFlags Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude GHC> }}} Some details which might help: {{{ ~/programming% uname -a Linux buckwheat 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux ~/programming% lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 7.10 Release: 7.10 Codename: gutsy ~/programming% ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} I installed GHC via the "ghc-6.8.2-i386-unknown-linux.tar.bz2" binary package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 06:09:29 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 06:02:05 2008 Subject: [GHC] #2336: trying to load a module (with GHC API) causes the impossible to happen In-Reply-To: <044.847e9ff48513cf34a3a9444172b4edf3@localhost> References: <044.847e9ff48513cf34a3a9444172b4edf3@localhost> Message-ID: <053.f09561cd032f9dcb0c976c9c9c94ad0e@localhost> #2336: trying to load a module (with GHC API) causes the impossible to happen ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Comment (by guest): On a closer look, it seems like the "panic" message may have come from the connected-to GHC, and may actually be the expected result. I sort of glossed over the "getDynamicFlags s >>= setDynamicFlags s" bit in the tutorial. With that line added, everything works like a charm. Feel free to mark this as invalid if that makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 06:18:53 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 06:11:39 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.f092fbfeb4b503f76b515b7b6f3bc60c@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): {{{ SRC_CC_OPTS += -std=gnu89 }}} in `config.mk.in` compiles now. I get the following warnings, though (that may not matter) {{{ ../compiler/ghc-inplace -optc-O -optc-std=gnu89 -optc-Wall -optc-W -optc- Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Hpc.c -o Hpc.o In file included from ../includes/ghcconfig.h:4, from ../includes/Stg.h:61, from ../includes/Rts.h:19, from Hpc.c:11:0: ../includes/ghcautoconf.h:359:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/stdio.h:22, from Hpc.c:5:0: /export/local1/mirror/lang/bin/../lib/gcc/i386-pc- solaris2.10/4.2.2/include/sys/feature_tests.h:197:1: warning: this is the location of the previous definition Hpc.c: In function 'hpc_init': Hpc.c:196:0: warning: format '%d' expects type 'int', but argument 5 has type 'pid_t' }}} and {{{ ../compiler/ghc-inplace -optc-O -optc-std=gnu89 -optc-Wall -optc-W -optc- Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-g -optc-O0 -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -H16m -O -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-DDEBUG -c sm/Storage.c -o sm/Storage.debug_o sm/Storage.c: In function 'initStorage': sm/Storage.c:123:0: warning: the address of 'stg_BLACKHOLE_info' will always evaluate as 'true' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 06:32:04 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 06:24:43 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken Message-ID: <045.1fd44b27076f8b28428287ad13138763@localhost> #2337: Data.Array documentation utterly broken ------------------------+--------------------------------------------------- Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- http://www.haskell.org/ghc/docs/latest/html/libraries/array/Data- Array.html vs http://www.haskell.org/ghc/docs/6.6-latest/html/libraries/base/Data- Array.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 06:58:03 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 06:50:42 2008 Subject: [GHC] #2334: panic using type families and type classes In-Reply-To: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> References: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> Message-ID: <054.620c82d6da73561f1d03fb748f3d878c@localhost> #2334: panic using type families and type classes ---------------------------+------------------------------------------------ Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Old description: > I got a panic while trying to compile some code using type families: > > ghc-6.9.20080528: panic! (the 'impossible' happened) > (GHC version 6.9.20080528 for i386-apple-darwin): > urk! lookup local fingerprint > > I can't post the code that caused that (yet) but when I was trying to > distill it down to its essence for a bug report, I got a different panic: > > ghc-6.9.20080528: panic! (the 'impossible' happened) > (GHC version 6.9.20080528 for i386-apple-darwin): > Prelude.head: empty list > > I've attached the code that caused it. I know the code might not be 100% > correct, and it's a bit long, but I think it might help some. New description: I got a panic while trying to compile some code using type families: {{{ ghc-6.9.20080528: panic! (the 'impossible' happened) (GHC version 6.9.20080528 for i386-apple-darwin): urk! lookup local fingerprint }}} I can't post the code that caused that (yet) but when I was trying to distill it down to its essence for a bug report, I got a different panic: {{{ ghc-6.9.20080528: panic! (the 'impossible' happened) (GHC version 6.9.20080528 for i386-apple-darwin): Prelude.head: empty list }}} I've attached the code that caused it. I know the code might not be 100% correct, and it's a bit long, but I think it might help some. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:04:39 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 06:57:16 2008 Subject: [GHC] #2334: panic using type families and type classes In-Reply-To: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> References: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> Message-ID: <054.db7e64b9708c713a17d9f59764e38cc9@localhost> #2334: panic using type families and type classes ---------------------------+------------------------------------------------ Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Comment (by simonmar): The following smaller example elicits the "Data.List.head: empty list" panic: {{{ {-# LANGUAGE TypeFamilies,EmptyDataDecls,MultiParamTypeClasses #-} module Test where data family F r newtype instance F () = F deriving Eq }}} and it seems to happen during Renamer/Typechecker. Removing "deriving (Eq)" makes the error go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:11:14 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:03:51 2008 Subject: [GHC] #2325: Compile-time computations In-Reply-To: <042.ec8f910033c06987836e7597539e54db@localhost> References: <042.ec8f910033c06987836e7597539e54db@localhost> Message-ID: <051.fe85c03f59c88702551b53782773ba4a@localhost> #2325: Compile-time computations --------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: constant folding | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by Isaac Dupree): Couldn't the desugarer treat them as Integers and the code generator deal with it later? (this assumes that GHC's integers and the boot-lib integers are extensionally equivalent, which should be a reasonable assumption!) (I'm sure I'm just being naive here? But do we really necessarily lose out for treating Integers as a unit we can understand rather than a composition of Int#s?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:19:36 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:12:22 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.9bf9b9522a2c01a775326f8b68ee3015@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): I've tried to set `CPPFLAGS = -D_XOPEN_SOURCE=600 -D__EXTENSIONS__` as described at http://wiki.netbsd.se/Typical_pkgsrc_error_messages without success. So I suggest to fix this issue using your first patch with `gnu89`! I had the above warnings already for ghc-6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:25:05 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:17:51 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.241295b0df701e2da7abcf9e50225e62@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): OK, I don't understand what's going on, but if it compiles then let's go with it! Is that only using `-std=gnu89`, or do you also need the `#define _XOPEN_SOURCE 600`? Thanks for all your testing! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:34:01 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:26:47 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.cfc66e420308ab515877635905cc320a@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): No, `_XOPEN_SOURCE 600` is not needed. I'm testing ghc-6.8.2.20080603 with Stg.h as is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 07:58:20 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:50:57 2008 Subject: [GHC] #2338: unpack primitive types by default in data? and NOUNPACK? Message-ID: <051.acef913b312de6cf127d683143b322b3@localhost> #2338: unpack primitive types by default in data? and NOUNPACK? --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- We should have a NOUNPACK pragma paralleling UNPACK so that we can unpack data types by default without completely taking away control from the programmer. (Currently, NOUNPACK would only have any effect when `-funbox-strict-fields` is given.) We may want to unpack strict primitive types by default (at least with -O), such as in the following {{{ data D a = D !Int !Double }}} (Because those are the types that it's most often useful to pass around in registers, for one thing?) But it's probably worth testing on a lot of existing code to make sure it's never too much of a penalty in practice. (But considering the amount that people just use `-funbox-strict-fields` without thinking, because having to place all those UNPACK pragmas is annoying, making the default be a little smarter is probably useful.) see parts of this thread: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/40294/focus=40316 related tickets, in order of decreasing relatedness: #605, #1349; #1433, #2289 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 08:04:06 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 07:56:44 2008 Subject: [GHC] #2336: trying to load a module (with GHC API) causes the impossible to happen In-Reply-To: <044.847e9ff48513cf34a3a9444172b4edf3@localhost> References: <044.847e9ff48513cf34a3a9444172b4edf3@localhost> Message-ID: <053.e2b37bd9db396076dbbfb95434417682@localhost> #2336: trying to load a module (with GHC API) causes the impossible to happen ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 09:23:22 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 09:15:59 2008 Subject: [GHC] #2175: stableptr003 fails In-Reply-To: <044.d06ef41a33cee91ab166dec272f5c106@localhost> References: <044.d06ef41a33cee91ab166dec272f5c106@localhost> Message-ID: <053.7ff5946a28c755dfecbfcf823066fcb9@localhost> #2175: stableptr003 fails ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Wed Jun 4 03:54:58 PDT 2008 Simon Marlow * fix pointer tagging bug in removeIndirections (fixes stableptr003) }}} and a testsuite fix: {{{ Wed Jun 4 01:29:07 PDT 2008 Simon Marlow * FIX #2175: evaluate the list first }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 09:26:01 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 09:18:41 2008 Subject: [GHC] #2334: panic using type families and type classes In-Reply-To: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> References: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> Message-ID: <054.8b0ef34638fd9ed4896fa5dbee52e1fb@localhost> #2334: panic using type families and type classes ---------------------------+------------------------------------------------ Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Changes (by simonmar): * milestone: => 6.10 branch Comment: The "lookup local fingerprint" crash is fixed by: {{{ Wed Jun 4 12:30:02 BST 2008 Simon Marlow * Fix #2334: tyvar binders can have Names inside (equality predicates) }}} The "Data.List.head: empty list" panic is still to be fixed, see above (and this is not my area, perhaps Simon or Manuel could take a look?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 09:54:47 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 09:47:22 2008 Subject: [GHC] #2339: Template Haskell reification with mkName doesn't work right Message-ID: <046.eda55845996fc4a6e7ea0ae33a7910dc@localhost> #2339: Template Haskell reification with mkName doesn't work right ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ Marc Weber writes: this doesn't work: {{{ -- packages: template-haskell {-# OPTIONS_GHC -XTemplateHaskell #-} module Main where import Language.Haskell.TH data A a = A a type C = A Int data ABC = ABC Int $(do a <- reify $ mkName "C" report False $ show a return [] ) main = print "" }}} Produces output {{{ || [1 of 1] Compiling Main ( test.hs, test.o ) || test.hs|1| `C' is not in scope at a reify }}} Using `mkName "A"` results in {{{ test.hs|1 error| || DataConI Main.A (ForallT [a_1627391370] [] (AppT (AppT ArrowT (VarT a_1627391370)) (AppT (ConT Main.A) (VarT a_1627391370)))) Main.A (Fixity 9 InfixL) }}} as expected Why do I need it? I'd like to implement kind of very basic relational data representation the way `IxSet` is doing it but without dynamics.. It will look like this: {{{ type CDs = Table (Autoinc, Artist, Title, Year) -- col types (Artist, Title, Year) -- keys () -- is detail of type Tracks = Table (Autoinc, Title, RecordingDate) (Title, RecordingDate) (CDs) $(mkDB ["CDs","Tracks"]) }}} To be able to automatically derive {{{ insert{CDs,Tracks} delete{CDs,Tracks} update{CDs,Tracks} }}} functions I need to get information about those types.. Is this possible? Thanks Marc Weber -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 10:00:19 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 09:52:56 2008 Subject: [GHC] #2339: Template Haskell reification with mkName doesn't work right In-Reply-To: <046.eda55845996fc4a6e7ea0ae33a7910dc@localhost> References: <046.eda55845996fc4a6e7ea0ae33a7910dc@localhost> Message-ID: <055.46f3b5872f3289c786d720632dd11bbf@localhost> #2339: Template Haskell reification with mkName doesn't work right ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_reifyMkName | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => TH_reifyMkName * owner: => simonpj Comment: Yes, there's a bug here, thank you. It would certainly be better to say {{{ reify ''C }}} as someone pointed out. That is the Right Way. But what you wrote should work too. I'm validating a fix now. There's still an ambiguity though. If you write {{{ data T = T Int $( ...reify (mkName "T")...) }}} then are you expecting the ''type constructor'' T or the ''data constructor'' T? My fix gives you the type constructor if there is one, and data constructor otherwise. But you can choose by using the quote notation, which is more robust. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 10:40:30 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 10:33:43 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.19d191626123613193530353b7c4445f@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by ingmar): * cc: ingmar@exherbo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:16:24 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:09:15 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.3f74b3a9a91f5c179f960fef8a41d712@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: OK, this is fixed for 6.8.3 by {{{ Wed Jun 4 06:01:17 PDT 2008 Ian Lynagh * Use -std=gnu89 on Solaris; fixes trac #2318 }}} but we will probably need to do something similar for 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:17:33 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:10:09 2008 Subject: [GHC] #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns In-Reply-To: <042.75c5254b7132afeaabac69b43afbc501@localhost> References: <042.75c5254b7132afeaabac69b43afbc501@localhost> Message-ID: <051.91b63ee46fb3f7ecfd0afe0381d45154@localhost> #2331: Bang pattern error message should suggest -XBangPatterns rather than -fbang-patterns ----------------------+----------------------------------------------------- Reporter: ajd | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:25:34 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:18:12 2008 Subject: [GHC] #2339: Template Haskell reification with mkName doesn't work right In-Reply-To: <046.eda55845996fc4a6e7ea0ae33a7910dc@localhost> References: <046.eda55845996fc4a6e7ea0ae33a7910dc@localhost> Message-ID: <055.3baa0ef5f9cc500a6fc3714c3aca5377@localhost> #2339: Template Haskell reification with mkName doesn't work right ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: simonpj Type: merge | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_reifyMkName | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * type: bug => merge * resolution: => fixed * cc: marco-oweber@gmx.de (added) Comment: Fixed by {{{ Wed Jun 4 16:02:07 BST 2008 simonpj@microsoft.com * Fix Trac #2339: reify (mkName "X") }}} I don't think this is worth merging to the branch -- we are too close to release, and there's an easy workaround (indeed the workaround is the Right Way). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:31:39 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:24:16 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts In-Reply-To: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> References: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> Message-ID: <053.efcf5a8e5fa36ee479c08842c93efd7a@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2310 | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonpj): * testcase: => T2310 * owner: => igloo * type: bug => merge Comment: Ah. You probably meant {{{ c = \(x::a) -> (x::a) }}} The example you actually give (now in tests `rename/should_fail/T2310.hs`) is the old syntax for "result signatures", which isn't supported any more. Better error report in {{{ Wed Jun 4 15:51:15 BST 2008 simonpj@microsoft.com * Fix Trac #2310: result type signatures are not supported any more }}} namely {{{ T2310.hs:5:21: Illegal result type signature `a' Result signatures are no longer supported in pattern matches In a lambda abstraction: \ x :: a -> (x :: a) }}} Maybe worth merging, since it fixes a crash. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:37:09 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:29:54 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.64ace61d8b0022fb516bf92467ce53a3@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): The compiler works: {{{ -bash-3.1$ compiler/stage2/ghc-inplace --interactive -package ghc GHCi, version 6.8.2.20080603: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.1 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.2 ... linking ... done. Loading package hpc-0.5.0.1 ... linking ... done. Loading package bytestring-0.9.0.1.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package unix-2.3.0.1 ... linking ... done. Loading package process-1.0.0.1 ... linking ... done. Loading package readline-1.0.1.0 ... linking ... done. Loading package Cabal-1.2.4.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.8.2.20080603 ... linking ... done. }}} but `gmake binary-dist` now produces the following error {{{ Generating a shippable configure script.. mv /export/local1/home/maeder/ghc-6.8.2.20080603/ghc-6.8.2.20080603 /configure-bin.ac /export/local1/home/maeder/ghc-6.8.2.20080603/ghc-6.8.2.20080603/configure.ac ( cd /export/local1/home/maeder/ghc-6.8.2.20080603/ghc-6.8.2.20080603; autoreconf ) Undefined subroutine &main::open_quote called at /usr/local/bin/autom4te line 273. Undefined subroutine &main::open_quote called at /usr/local/bin/autom4te line 273. autoreconf: /usr/local/bin/autoconf failed with exit status: 1 gmake: *** [binary-dist] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:47:53 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:40:32 2008 Subject: [GHC] #2340: Improve Template Haskell error recovery Message-ID: <046.869c20c62dd7ab567cd622b9021b6c1e@localhost> #2340: Improve Template Haskell error recovery --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Marc Weber wants better error recovery in TH's Q monad: http://www.haskell.org/pipermail/template-haskell/2008-May/000666.html The Quasi monad is defined thus: {{{ class (Monad m, Functor m) => Quasi m where -- Fresh names qNewName :: String -> m Name -- Error reporting and recovery qReport :: Bool -> String -> m () -- Report an error (True) or warning (False) -- ...but carry on; use 'fail' to stop qRecover :: m a -> m a -> m a -- Recover from the monadic 'fail' -- The first arg is the error handler -- Inspect the type-checker's environment qReify :: Name -> m Info qLocation :: m Loc -- Input/output (dangerous) qRunIO :: IO a -> m a }}} A sensible change (but it would be a change) would be to change `qRecover` thus: {{{ qRecover :: m a -> ([(Bool,String)] -> m a) -> m a -- (qRecover q f) runs the action `q`, collecting all the messages -- emitted by `qReport`. If the action `q` calls the monad `fail`, -- these messages are passed to `f`. If the action `q` does not call -- `fail`, the messages are retained in the monad, just as if the -- `qRecover` was not there. }}} Comments? This would be quite easy to implement in 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 11:51:08 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 11:43:52 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.d2fcec754829fe00999582e36507c1e4@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): {{{ -bash-3.1$ autoconf --version autoconf (GNU Autoconf) 2.62 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 13:40:36 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 13:33:11 2008 Subject: [GHC] #2341: GHC crashed my mac, said I should report it Message-ID: <044.825f171b9c6daeba1f2407deabe71d6d@localhost> #2341: GHC crashed my mac, said I should report it ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: MacOS X ------------------------+--------------------------------------------------- GHC died with: "evaluate(static): strange closure type 271" GHC version 6.8.2 for i386_apple_darwin -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 14:05:43 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 13:58:26 2008 Subject: [GHC] #2341: GHC crashed my mac, said I should report it In-Reply-To: <044.825f171b9c6daeba1f2407deabe71d6d@localhost> References: <044.825f171b9c6daeba1f2407deabe71d6d@localhost> Message-ID: <053.c6e9fc36de15ed1bb67e560f02aa1b10@localhost> #2341: GHC crashed my mac, said I should report it -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by maeder): How can we reproduce this error? Which distribution did you install? http://www.haskell.org/ghc/dist/6.8.2/chakravarty/ghc-6.8.2-i386-apple- darwin.tar.bz2 or http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-apple- darwin.tar.bz2 or other? Can we email you for clarification? Thanks for your report anyway, maybe someone else got the same error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 14:12:05 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 14:04:48 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 Message-ID: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- {{{ ../../compiler/stage1/ghc-inplace -package-name base-3.0.2.0 -hide-all- packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP -idist/build -H16m -O -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -O -Rghc-timing -fgenerics -c GHC/Base.lhs -o dist/build/GHC/Base.o -ohi dist/build/GHC/Base.hi In file included from include/HsBase.h:109, from /tmp/ghc13901_0/ghc13901_0.hc:4:0: /usr/include/sys/resource.h:146:0: error: field 'ru_utime' has incomplete type /usr/include/sys/resource.h:147:0: error: field 'ru_stime' has incomplete type In file included from /tmp/ghc13901_0/ghc13901_0.hc:4:0: include/HsBase.h: In function 'sizeofTimeVal': include/HsBase.h:721:0: error: invalid application of 'sizeof' to incomplete type 'struct timeval' include/HsBase.h: In function 'getUSecOfDay': include/HsBase.h:725:0: error: storage size of 'tv' isn't known include/HsBase.h: In function 'setTimevalTicks': include/HsBase.h:735:0: error: dereferencing pointer to incomplete type include/HsBase.h:736:0: error: dereferencing pointer to incomplete type <> gmake[2]: *** [dist/build/GHC/Base.o] Error 1 gmake[2]: Leaving directory `/export/local/home/maeder/ghc-6.8.2.20080603/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/export/local/home/maeder/ghc-6.8.2.20080603/libraries' gmake: *** [stage1] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 14:21:18 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 14:14:04 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.50b657f8219f88df3809affe60f84a76@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): It works for me with {{{ $ autoreconf --version autoreconf (GNU Autoconf) 2.62 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. }}} (Debian's 2.62-1 package). Line 273 of `/usr/bin/autom4te` is {{{ my $cfg = new Autom4te::XFile ("< " . open_quote ($file)); }}} and the function is defined in `/usr/share/autoconf/Autom4te/FileUtils.pm`, so it looks to me like your autoconf installation is broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 14:52:08 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 14:44:53 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.f29dcba685034468bd0c353f4f3c0101@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.8.3 Comment: Hmm, does this patch against `libraries/base/include/HsBase.h` fix it? {{{ diff -rN -u old-base/include/HsBase.h new-base/include/HsBase.h --- old-base/include/HsBase.h 2008-06-04 19:49:08.000000000 +0100 +++ new-base/include/HsBase.h 2008-06-04 19:49:08.000000000 +0100 @@ -67,11 +67,10 @@ #if HAVE_SYS_UTSNAME_H #include #endif -#if HAVE_GETTIMEOFDAY -# if HAVE_SYS_TIME_H -# include -# endif -#elif HAVE_GETCLOCK +#if HAVE_SYS_TIME_H +#include +#endif +#if HAVE_GETCLOCK # if HAVE_SYS_TIMERS_H # define POSIX_4D9 1 # include }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 15:50:30 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 15:43:06 2008 Subject: [GHC] #2343: Docs are installed to a peculiar location Message-ID: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> #2343: Docs are installed to a peculiar location ------------------------+--------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Working with the ghc-6.8.2.20080603 snapshot, I run into a problem whereby the generated haddocks are installed to the root of the filesystem, instead of the destination I specify. This is a change in behaviour from 6.8.2. (By the way, I'm using haddock 0.8, if that has any significance.) Here is how I am setting up the build: {{{ ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man }}} After the main build succeeds, I install as follows: {{{ make DESTDIR=/var/tmp/ghc-6.8.2.20080603-1.fc9-root-bos libdir=/usr/lib64/ghc-6.8.2.20080603 install make DESTDIR=/var/tmp/ghc-6.8.2.20080603-1.fc9-root-bos XMLDocWays=html HADDOCK_DOCS=YES install-docs }}} The main `install` target seems to have no problems, but `install-docs` installs everything to `$DESTDIR`, not to the docdir subdirectory of `$DESTDIR` that used to work with 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 18:56:16 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 18:48:52 2008 Subject: [GHC] #2344: oddity with package prefixes for data constructors Message-ID: <044.af9be20076cbcfaeedab766401f29420@localhost> #2344: oddity with package prefixes for data constructors ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- consider {{{ $ ./ghc-6.9.20080514/bin/ghcii.sh GHCi, version 6.9.20080514: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :browse Data.Time.Clock getCurrentTime :: IO UTCTime newtype DiffTime = time-1.1.2.0:Data.Time.Clock.Scale.MkDiffTime Data.Fixed.Pico newtype NominalDiffTime = time-1.1.2.0:Data.Time.Clock.UTC.MkNominalDiffTime Data.Fixed.Pico data UTCTime = UTCTime {utctDay :: time-1.1.2.0:Data.Time.Calendar.Days.Day, utctDayTime :: DiffTime} newtype UniversalTime = ModJulianDate {getModJulianDate :: Rational} addUTCTime :: NominalDiffTime -> UTCTime -> UTCTime diffUTCTime :: UTCTime -> UTCTime -> NominalDiffTime picosecondsToDiffTime :: Integer -> DiffTime secondsToDiffTime :: Integer -> DiffTime }}} there is only one time package installed, so i'm surprised to see any package prefixes at all here {{{ $ ./ghc-6.9.20080514/bin/ghc-pkg.exe find-module Data.Time.\* c:/fptools/ghc/ghc-6.9.20080514\package.conf: time-1.1.2.0 }}} but by what system do some things get prefixes and others don't? are there any invisible modules that need the distinction, or is this an output bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 19:16:26 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 19:09:03 2008 Subject: [GHC] #2345: :browse limitations (browsing virtual namespaces, listing namespaces) Message-ID: <044.b5a5c824d7248b2cf228e752ae42706b@localhost> #2345: :browse limitations (browsing virtual namespaces, listing namespaces) --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- 1. :browse cannot be used with virtual namespaces: {{{ import Prelude () import qualified Data.List as Folds(foldr) import qualified Data.Maybe as Folds(maybe) }}} {{{ *Main> :browse *Main Folds.foldr :: (a -> b -> b) -> b -> [a] -> b Folds.maybe :: b -> (a -> b) -> Data.Maybe.Maybe a -> b *Main> :browse *Folds Could not find module `Folds': Use -v to see a list of the files searched for. }}} it would be useful if GHCi's :browse supported this Haskell module system feature, allowing "virtual" namespaces to be browsed just like "real" ones. 2. to use :browse, one needs to know the precise module name when using some packages, like OpenGL, i never can remember where in the hierarchy their modules are placed, so i can't even get started :browsing them. (a) it would be useful if `ghc-pkg` functionality was part of the `GHC API`, and accessible from within GHCi, or if GHCi knew which instance of `ghc-pkg` it is associated with (`:!ghc-pkg field OpenGL exposed-modules` does not work unless the ghc-pkg in the PATH happens to match the GHCi in use..). (b) it would be nicer if GHCi's `:browse` itself had an option to list available namespaces matching a pattern, so that one could narrow down to what one wants to `:browse` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 20:45:16 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 20:37:51 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM Message-ID: <046.285595109907aedbac69f385749bac00@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------+--------------------------------------------------- Reporter: choener | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux ------------------------+--------------------------------------------------- We have automatically generated source files with up to ~20000 lines of code. One type definition, two functions called "grammar" (cmGrammer, ghGrammar) and one or more functions called "algebra" (prettyprint, scoremax, count, ***) are generated. Each function has a where-clause with 100+ locally visible function defined. Attached, you find two files (ADPTriCombinators.lhs, RnaI.lhs) with helper-functions and three of our source files. One is the smallest example we have and the other the largest. RF00549RED.hs is reduced to only the type, one algebra and one grammar. Copy all files into a directory and then execute: ghc --make RF00390.hs (should work) ghc --make RF00549.hs (WARNING: EATS ALL MEMORY) ghc --make RF00549RED.hs (WARNING: EATS ALL MEMORY) System Info: ============ Linux workstation 2.6.25-ARCH #1 SMP PREEMPT Fri May 16 14:52:43 CEST 2008 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux (2 GByte RAM, 2 GByte Swap) gcc version 4.3.0 (GCC) Thanks, Christian H?ner zu Siederdissen -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 21:51:30 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 21:44:04 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.8c190bcdb12deaf0490f17a46cb802bc@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Here's where I am so far, using http://haskell.org/docon/distrib/2.11/docon-2.11.zip With 6.8.3 RC: {{{ $ ghc -O -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable- instances -O --make RsePol_.hs -fforce-recomp +RTS -M400M [...] $ ghc -O -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable- instances -O -c RsePol_.hs -fforce-recomp -v +RTS -M400M [...] *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 3830 *** Simplify: Result size = 2895 Result size = 2691 Result size = 2689 Result size = 2689 *** Specialise: Result size = 2689 *** Float out (not lambdas, not constants): Result size = 2751 *** Float inwards: Result size = 2751 *** Simplify: Heap exhausted; Current maximum heap size is 399998976 bytes (381 Mb); }}} while 6.8.2 goes: {{{ [...] *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 3827 *** Simplify: Result size = 2899 Result size = 2701 Result size = 2699 Result size = 2699 *** Specialise: Result size = 2699 *** Float out (not lambdas, not constants): Result size = 2768 *** Float inwards: Result size = 2768 *** Simplify: Result size = 309049 Result size = 216314 Result size = 81507 [...] }}} (and is also happy with a 200M heap). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 4 22:01:26 2008 From: trac at galois.com (GHC) Date: Wed Jun 4 21:54:24 2008 Subject: [GHC] #2347: x86_64-*-netbsd can be added to mangler target platforms Message-ID: <043.a54819edde4ee1170c8d5536df6e4a3c@localhost> #2347: x86_64-*-netbsd can be added to mangler target platforms -------------------------------+-------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: NetBSD -------------------------------+-------------------------------------------- driver/mangler/ghc-asm.lprl works on NetBSD-amd64, needing only "netbsd" inserted among freebsd, linux, openbsd ca. line 219 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 00:20:45 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 00:13:20 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.0706dbeeb8aa4471136cf71b1777b3bb@localhost> #2346: Compilation of large source files requires a lot of RAM ---------------------------------------------+------------------------------ Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------------------------+------------------------------ Changes (by ajd): * type: bug => compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 02:46:50 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 02:39:53 2008 Subject: [GHC] #2348: x86_64-unknown-netbsd can be a supported platform Message-ID: <043.0c34f3aad4366c5bfad8c45429c61dd1@localhost> #2348: x86_64-unknown-netbsd can be a supported platform -------------------------------+-------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: NetBSD -------------------------------+-------------------------------------------- The top level configure.ac should include x86_64-unknown-netbsd as a supported platform. The case branch can be identical to x86_64-unknown- freebsd, etc., mutatis mutando: --- configure.ac.dist 2008-06-03 10:21:17.000000000 -0700 +++ configure.ac 2008-06-04 18:28:37.000000000 -0700 @@ -161,6 +161,15 @@ HostVendor_CPP='unknown' HostOS_CPP='openbsd' ;; +amd64-*-netbsd*|x86_64-*-netbsd*) + HostPlatform=x86_64-unknown-netbsd + TargetPlatform=x86_64-unknown-netbsd + BuildPlatform=x86_64-unknown-netbsd + HostPlatform_CPP='x86_64_unknown_netbsd' + HostArch_CPP='x86_64' + HostVendor_CPP='unknown' + HostOS_CPP='netbsd' + ;; amd64-*-freebsd*|x86_64-*-freebsd*) HostPlatform=x86_64-unknown-freebsd TargetPlatform=x86_64-unknown-freebsd -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 04:13:36 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 04:06:23 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.b2950376d65f43dba90a65ba7aedda18@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): Right, our file /usr/local/share/autoconf/Autom4te/FileUtils.pm is old and does not contain open_quote -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 04:46:45 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 04:39:19 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> Message-ID: <053.9b01b674c82f63a26f9ed234aa51eeb5@localhost> #2305: GHC does not care __RENAME macro -----------------------------+---------------------------------------------- Reporter: iquiw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This is not a bug, as such - or rather, it's a bug in the via-C backend that it actually works when compiling with -fvia-C (we fixed this recently in HEAD). The FFI is defined to interface to the C ABI rather than the C API; it doesn't take account of CPP magic. To work around this you typically need to call a C wrapper via the FFI rather than calling the C function directly. The C wrapper lives in a .c file and gets compiled by the C compiler. We have lots of these scattered about the libraries already. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 04:53:24 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 04:46:06 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.a74d6c4eee06a02d4673a00a7f060ae7@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): Same problem, I'll attach the header files time.h and resource.h from /usr/include/sys/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 04:55:02 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 04:47:56 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> Message-ID: <053.75db26df72b70774a6d5581c6c65d979@localhost> #2305: GHC does not care __RENAME macro -----------------------------+---------------------------------------------- Reporter: iquiw | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: closed => reopened * cc: donn@avvanta.com (added) * resolution: invalid => Comment: But Don Cave records in this email that the libraries we ship with GHC are missing some such wrappers. So really this is an open bug until someone adds the wrappers to the appropriate libraries. Thus I'm re-opening. (Re-close if I'm under a mis-apprehension.) http://www.haskell.org/pipermail/glasgow-haskell- users/2008-June/014871.html Don can you tell us which are the offending libraries and C imports? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Thu Jun 5 05:11:02 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 5 05:03:37 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <053.9b01b674c82f63a26f9ed234aa51eeb5@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> <053.9b01b674c82f63a26f9ed234aa51eeb5@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE59B9EE6@EA-EXMSG-C334.europe.corp.microsoft.com> I've augmented the Using-the-FFI page too. I hope I got it right. http://haskell.org/haskellwiki/GHC/Using_the_FFI#Importing_C_functions_that_turn_out_to_be_CPP_macros Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On | Behalf Of GHC | Sent: 05 June 2008 09:47 | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #2305: GHC does not care __RENAME macro | | #2305: GHC does not care __RENAME macro | -----------------------------+---------------------------------------------- | Reporter: iquiw | Owner: | Type: feature request | Status: closed | Priority: normal | Milestone: | Component: Compiler (FFI) | Version: 6.8.2 | Severity: normal | Resolution: invalid | Keywords: | Difficulty: Unknown | Testcase: | Architecture: Unknown | Os: NetBSD | | -----------------------------+---------------------------------------------- | Changes (by simonmar): | | * status: new => closed | * difficulty: => Unknown | * resolution: => invalid | | Comment: | | This is not a bug, as such - or rather, it's a bug in the via-C backend | that it actually works when compiling with -fvia-C (we fixed this recently | in HEAD). The FFI is defined to interface to the C ABI rather than the C | API; it doesn't take account of CPP magic. | | To work around this you typically need to call a C wrapper via the FFI | rather than calling the C function directly. The C wrapper lives in a .c | file and gets compiled by the C compiler. We have lots of these scattered | about the libraries already. | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 05:21:59 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 05:14:31 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.7667d3a97b076fc06771f7984c391a65@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by simonpj): I believe that the massive (150x!) blow-up when the Simplifier gets going is because instance declarations are inlined bodily. !DoCon uses a lot of instances, and the effect is very substantial. As it happens I've been working on a fix, because I've been aware of this for some time, but it's too big a fix to put in 6.8.2. The change between 6.8.2 and 6.8.3 is mysterious though. I don't understand that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From claus.reinke at talk21.com Thu Jun 5 05:53:09 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jun 5 05:45:47 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost><053.9b01b674c82f63a26f9ed234aa51eeb5@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE59B9EE6@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <012101c8c6f1$f80d2c50$961a8351@cr3lt> > I've augmented the Using-the-FFI page too. I hope I got it right. > > http://haskell.org/haskellwiki/GHC/Using_the_FFI#Importing_C_functions_that_turn_out_to_be_CPP_macros hmm. and what if the CPP/C status of a function fluctuates (different OS/library versions/..)? does the simple binding then become an exorcise is autoconf? mingw, e.g., has had a habit of being different there at times. CPP is part of C (well, it was a long time ago, at least), and those wrappers look like something that could and should be automated, like other wrappers in the FFI. perhaps ghc feeding those foreign imports to gcc, when in doubt, and linking in the result? claus From trac at galois.com Thu Jun 5 07:22:35 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 07:15:09 2008 Subject: [GHC] #2344: oddity with package prefixes for data constructors In-Reply-To: <044.af9be20076cbcfaeedab766401f29420@localhost> References: <044.af9be20076cbcfaeedab766401f29420@localhost> Message-ID: <053.f7e6b4b6247ce5304a98c6ea07056da3@localhost> #2344: oddity with package prefixes for data constructors ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: When you say ':browse M', GHCi pretends you've imported module M for the purposes of determining what's in scope. Everything not exported by M is out of scope, and in order to be completely unambiguous about which names are meant, GHCi gives the fully-qualified name including the package. The package prefixes are a bit unfortunate because they aren't valid syntax for one thing. OTOH, there might be no way to refer to the identifier in question at all using just a module qualifier. I don't really know how to improve this easily. Are you worried about consuming the output of :browse by a tool, or just using it interactively? -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu Jun 5 07:27:09 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 5 07:19:46 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <053.75db26df72b70774a6d5581c6c65d979@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> <053.75db26df72b70774a6d5581c6c65d979@localhost> Message-ID: <4847CD8D.3000508@gmail.com> GHC wrote: > #2305: GHC does not care __RENAME macro > -----------------------------+---------------------------------------------- > Reporter: iquiw | Owner: > Type: feature request | Status: reopened > Priority: normal | Milestone: > Component: Compiler (FFI) | Version: 6.8.2 > Severity: normal | Resolution: > Keywords: | Difficulty: Unknown > Testcase: | Architecture: Unknown > Os: NetBSD | > -----------------------------+---------------------------------------------- > Changes (by simonpj): > > * status: closed => reopened > * cc: donn@avvanta.com (added) > * resolution: invalid => > > Comment: > > But Don Cave records in this email that the libraries we ship with GHC are > missing some such wrappers. So really this is an open bug until someone > adds the wrappers to the appropriate libraries. Thus I'm re-opening. > (Re-close if I'm under a mis-apprehension.) I thougt we ought to have a separate ticket for the NetBSD-specific bug. Not a big deal though. Cheers, Simon From trac at galois.com Thu Jun 5 07:49:43 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 07:43:30 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.68dca2a47830db964f2403055b5a2e1e@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): OK, I think that this patch should get `_XPG4_2` defined, and thus make `struct timeval` be defined: {{{ diff -rN -u old-ghc/includes/Stg.h new-ghc/includes/Stg.h --- old-ghc/includes/Stg.h 2008-06-03 21:59:00.000000000 +0100 +++ new-ghc/includes/Stg.h 2008-06-03 21:59:00.000000000 +0100 @@ -49,7 +49,7 @@ // And finally, we need _XOPEN_SOURCE in order to get a prototype for // putenv on Linux: -#define _XOPEN_SOURCE +#define _XOPEN_SOURCE 600 #endif }}} Can you give it a whirl please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 08:50:34 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 08:43:08 2008 Subject: [GHC] #2344: oddity with package prefixes for data constructors In-Reply-To: <044.af9be20076cbcfaeedab766401f29420@localhost> References: <044.af9be20076cbcfaeedab766401f29420@localhost> Message-ID: <053.040619dc3f32898407dd535145d1705e@localhost> #2344: oddity with package prefixes for data constructors -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by claus): * type: bug => feature request Comment: ah, i see. so it is really telling me that the thing is not in scope, while giving me an indication of what it is that is not in scope. i first noticed the effect via the type tooltips in my haskellmode plugins for vim, which are derived from interpreting the output of `:browse! *Main`. now i see that the difference is between {{{ import Prelude() import Data.Time.Clock(getCurrentTime,UTCTime) }}} which gives the type of `getCurrentTime` as `GHC.IOBase.IO UTCTime`, and {{{ import Prelude() import Data.Time.Clock(getCurrentTime) --,UTCTime) }}} which gives the type as `GHC.IOBase.IO time-1.1.2.0:Data.Time.Clock.UTC.UTCTime`. okay, so there is a system to this. but the presence of the package prefix alone does not always imply "not in scope", does it? perhaps some way of indicating the "not in scope" aspect would be useful (putting it in braces perhaps?). anyway, i'm changing this to a feature request. it isn't a bug, just a little odd and unexpected, and perhaps someone finds a way to make it less odd, but it isn't high priority. thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 08:51:47 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 08:44:20 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.52a5f1b27c474c598276a888ce35d856@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by igloo): The problem seems to be that this patch: {{{ [MERGED: Inline implication constraints Ian Lynagh **20071215163315 Mon Nov 5 22:08:07 GMT 2007 simonpj@microsoft.com This patch fixes Trac #1643, where Lennart found that GHC was generating code with unnecessary dictionaries. The reason was that we were getting an implication constraint floated out of an INLINE (actually an instance decl), and the implication constraint therefore wasn't inlined even though it was used only once (but inside the INLINE). Thus we were getting: ic = \d -> foo = _inline_me_ (...ic...) Then 'foo' gets inlined in lots of places, but 'ic' now looks a bit big. But implication constraints should *always* be inlined; they are just artefacts of the constraint simplifier. This patch solves the problem, by adding a WpInline form to the HsWrap type. }}} makes more things inlinable, and thus requires more space. Reverting the patch gets us back to 6.8.2 performance. Should I revert it in the 6.8 branch, Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 08:53:08 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 08:45:42 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.7f101ec73738bd269e71cf01fb147029@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------------------------+--------------------------------- Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > We have automatically generated source files with up to ~20000 lines of > code. > > One type definition, two functions called "grammar" (cmGrammer, > ghGrammar) and one or more functions called "algebra" (prettyprint, > scoremax, count, ***) are generated. Each function has a where-clause > with 100+ locally visible function defined. > > Attached, you find two files (ADPTriCombinators.lhs, RnaI.lhs) with > helper-functions and three of our source files. One is the smallest > example we have and the other the largest. RF00549RED.hs is reduced to > only the type, one algebra and one grammar. > > Copy all files into a directory and then execute: > ghc --make RF00390.hs (should work) > ghc --make RF00549.hs (WARNING: EATS ALL MEMORY) > ghc --make RF00549RED.hs (WARNING: EATS ALL MEMORY) > > > System Info: > ============ > Linux workstation 2.6.25-ARCH #1 SMP PREEMPT Fri May 16 14:52:43 CEST > 2008 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux (2 > GByte RAM, 2 GByte Swap) > > gcc version 4.3.0 (GCC) > > Thanks, > Christian H?ner zu Siederdissen New description: We have automatically generated source files with up to ~20000 lines of code. One type definition, two functions called "grammar" (cmGrammer, ghGrammar) and one or more functions called "algebra" (prettyprint, scoremax, count, ***) are generated. Each function has a where-clause with 100+ locally visible function defined. Attached, you find two files (ADPTriCombinators.lhs, RnaI.lhs) with helper-functions and three of our source files. One is the smallest example we have and the other the largest. RF00549RED.hs is reduced to only the type, one algebra and one grammar. Copy all files into a directory and then execute: {{{ ghc --make RF00390.hs (should work) ghc --make RF00549.hs (WARNING: EATS ALL MEMORY) ghc --make RF00549RED.hs (WARNING: EATS ALL MEMORY) }}} System Info: {{{ Linux workstation 2.6.25-ARCH #1 SMP PREEMPT Fri May 16 14:52:43 CEST 2008 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux (2 GByte RAM, 2 GByte Swap) gcc version 4.3.0 (GCC) }}} Thanks, Christian H?ner zu Siederdissen -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 09:43:31 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 09:36:03 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.32dabb4aa705fd301db043ce4b4a075a@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by simonpj): Good catch! I'm not sure about reverting, though, because I think it may worsen runtime performance in quite ordinary programs. I'm inclined to keep this one firmly on the radar, but wait see how my upcoming change to instances affects it. Meanwhile, Serge may have to compile with 6.8.2, which is, I admit, rather unsatisfactory. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 09:47:24 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 09:40:05 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.dc6e4fe5dbb7f7d3b4139cbaec0d6f7e@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): This patch caused the following error message {{{ ../compiler/ghc-inplace -H16m -O -optc-mcpu=ultrasparc -opta- mcpu=ultrasparc -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o In file included from /usr/include/sys/types.h:18, from /usr/local/include/stdint.h:2, from /export/local/home/maeder/ghc-6.8.2.20080603/includes/HsFFI.h:31, from /export/local/home/maeder/ghc-6.8.2.20080603/includes/RtsAPI.h:16, from /export/local/home/maeder/ghc-6.8.2.20080603/includes/RtsExternal.h:13, from /export/local/home/maeder/ghc-6.8.2.20080603/includes/Stg.h:182, from /tmp/ghc27097_0/ghc27097_0.hc:3:0: /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun- solaris2.10/4.2.2/include/sys/feature_tests.h:345:2: error: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" gmake[1]: *** [Apply.o] Error 1 gmake: *** [stage1] Error 1 }}} I'm trying now with "gnu89" (as under i386 Solaris) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 10:03:38 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 09:57:05 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version Message-ID: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- the file `includes/mkDerivedConstants.c` of release candidate ghc-6.8.2.20080603 contains: {{{ #ifdef mingw32_HOST_OS #define SIZET_FMT "d" #else #define SIZET_FMT "zd" #endif }}} this produced unusable header file containing "zd" instead of integers under SunOS 5.8 Generic_117350-54 sun4u sparc SUNW,Ultra-4. However the very same binary `includes/mkGHCConstants` works correctly under SunOS 5.10 Generic_127111-03 sun4u sparc SUNW,Sun-Fire-280R -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 10:34:01 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 10:26:34 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.e577cd1ed4cf3c6c821e43488ea6d5d5@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonpj Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * owner: => simonpj * milestone: 6.8.3 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:09:03 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:01:44 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.322be9164f53aae34c1b5c4b40829bb4@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): `_XOPEN_SOURCE 600` does not go together with `-std=gnu89` and the initial problem is unsolved -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:32:32 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:25:14 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.4e95e3e83fab3755f00cc78f8c20e114@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): What happens? "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99"? If so, does defining _XOPEN_SOURCE to be 500 work? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:38:02 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:30:46 2008 Subject: [GHC] #2350: hSetEcho: failed (failed to set echoing) on Windows Message-ID: <046.f635148d87eda19915274a731d766966@localhost> #2350: hSetEcho: failed (failed to set echoing) on Windows ------------------------+--------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The attached program fails under Windows. It tries to do a hSetEcho on stdout. The error I get is {{{ get-echo: : hSetEcho: failed (failed to set echoing) }}} P.S. This is me trying to look into darcs bug http://bugs.darcs.net/issue774 . Any hints for that appreciated on our tracker -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:40:58 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:33:33 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.8a3e526f80c8b655c929e88d085c810a@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2045 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * testcase: => T2045 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ * Fix Trac #2045: use big-tuple machiney for implication constraints M ./compiler/deSugar/DsUtils.lhs -5 +5 M ./compiler/typecheck/TcSimplify.lhs -8 +8 }}} Might be worth trying to merge this to the 6.8 branch Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:56:44 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:49:22 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.ec864fe3300f26f37cc1003f53639ec9@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2045 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): Oops: you also need this patch too, sorry {{{ Thu Jun 5 17:54:34 BST 2008 simonpj@microsoft.com * Vital follow-up to fix of Trac #2045 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 5 12:57:36 2008 From: trac at galois.com (GHC) Date: Thu Jun 5 12:50:13 2008 Subject: [GHC] #2334: panic using type families and type classes In-Reply-To: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> References: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> Message-ID: <054.e14694920c41e157f4f1f44498c7ce52@localhost> #2334: panic using type families and type classes ---------------------------+------------------------------------------------ Reporter: pgavin | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I'm working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 03:51:01 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 03:43:40 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.1ec8fd088b047c11c0c13a658ef04475@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): Building and installing went through now. http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-6.8.2.20080603-i386-unknown-solaris2.tar.bz2 Here are my final warnings (just for the record) {{{ configure.ac:147: warning: AC_CACHE_VAL(fp_gcc_version, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from... aclocal.m4:548: FP_HAVE_GCC is expanded from... configure.ac:147: the top level configure.ac:147: warning: AC_CACHE_VAL(fp_gcc_version, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from... aclocal.m4:548: FP_HAVE_GCC is expanded from... configure.ac:147: the top level ( cd /export/local1/home/maeder/ghc-6.8.2.20080603; tar cf - ghc-6.8.2.20080603 | bzip2 >/export/local1/home/maeder/ghc-6.8.2.20080603/ghc-6.8.2.20080603-i386 -unknown-solaris2.tar.bz2 ) tar: ghc-6.8.2.20080603/compiler/stage2/DEPEND-NOTES/DLL- NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin/NOTES/Simon- log/basicTypes/cbits/cmm/codeGen/coreSyn/count_bytes/count_lines/cprAnalysis/deSugar /ghc-inplace/ghc-inplace.c/ghci/hsSyn/iface/ilxGen: prefix is greater than 155 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 03:57:48 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 03:50:25 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.c08dbe1c4f3d802d0b7badf29e105d0b@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): Yes, _XOPEN_SOURCE 600 causes "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99", but 500 (and -std=gnu89) works! (It's not finished yet, but beyond GHC/Base) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 04:10:23 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 04:03:02 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris with gcc-4.2.2 In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.880eb4ad4fbcbf58c4b14607189ce922@localhost> #2312: object splitting is not done under sparc solaris with gcc-4.2.2 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by maeder): * summary: object splitting is not done under sparc solaris => object splitting is not done under sparc solaris with gcc-4.2.2 Comment: This is also still a problem for the release candidate ghc-6.8.2.20080603 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 04:42:06 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 04:34:44 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.c05d96ace2e4e8deec3463878027a9a5@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): A similar problem occurs now for libraries/old-time {{{ ../../compiler/stage1/ghc-inplace -package-name old-time-1.0.0.0 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsTime.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package old- locale-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H16m -O -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -O -Rghc-timing -fgenerics -c dist/build/System/Time.hs -o dist/build/System/Time.o -ohi dist/build/System/Time.hi /tmp/ghc4604_0/ghc4604_0.hc: In function 'oldzmtimezm1zi0zi0zi0_SystemziTime_zdLr69ZZzdwa1_entry': /tmp/ghc4604_0/ghc4604_0.hc:3200:0: error: 'altzone' undeclared (first use in this function) /tmp/ghc4604_0/ghc4604_0.hc:3200:0: error: (Each undeclared identifier is reported only once /tmp/ghc4604_0/ghc4604_0.hc:3200:0: error: for each function it appears in.) <> gmake[2]: *** [dist/build/System/Time.o] Error 1 gmake[2]: Leaving directory `/export/local/home/maeder/ghc-6.8.2.20080603/libraries/old-time' gmake[1]: *** [make.library.old-time] Error 2 gmake[1]: Leaving directory `/export/local/home/maeder/ghc-6.8.2.20080603/libraries' gmake: *** [stage1] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 07:02:10 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 06:56:41 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.bd05027167b03e9b9c2ea28b7ad711fc@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): What an include madness. Adding `extern long altzone;` manually to libraries/old-time/include/HsTime.h allowed me to continue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 08:55:22 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 08:47:52 2008 Subject: [GHC] #2343: Docs are installed to a peculiar location In-Reply-To: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> References: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> Message-ID: <051.28f84d1619ce609a8ee4a2a498eac484@localhost> #2343: Docs are installed to a peculiar location ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: I don't understand what's going on here. Do you have a `mk/build.mk`? What other commands are you running? Just plain `make` between configuring and installing? `install-docs` shouldn't be installing the haddocks, `install` should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:10:57 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:03:37 2008 Subject: [GHC] #2334: panic using type families and type classes In-Reply-To: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> References: <045.1dc506e6a74f6c75c601641a3c948b5b@localhost> Message-ID: <054.ae50547a29c58a13e975119a4e6fe99f@localhost> #2334: panic using type families and type classes ---------------------------------+------------------------------------------ Reporter: pgavin | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: type families | Difficulty: Unknown Testcase: indexed-types/T2334 | Architecture: x86 Os: MacOS X | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => indexed-types/T2334 * status: new => closed * resolution: => fixed Comment: Fixed {{{ Fri Jun 6 13:17:30 BST 2008 simonpj@microsoft.com * Fix Trac #2334: validity checking for type families }}} Type families aren't advertised in 6.8, so no need to merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:19:17 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:11:57 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris with gcc-4.2.2 In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.f195731674129b5140d33b34a1280ea7@localhost> #2312: object splitting is not done under sparc solaris with gcc-4.2.2 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by igloo): If you look at the `.raw_s` files you can see that gcc 4.2.2 has floated all the `__stg_split_marker`'s to the top. On other platforms `-fno-unit- at-a-time` or `-fno-toplevel-reorder` have fixed this; can you find a flag to fix it for you? For experimenting, you can compile something with `ghc -v -keep-tmp-files` and then rerun the `gcc` command that `ghc` runs with different flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:30:06 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:22:44 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris with gcc-4.2.2 In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.6f89398b2f0e950f942401c598c25685@localhost> #2312: object splitting is not done under sparc solaris with gcc-4.2.2 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): Right, -fno-toplevel-reorder alone does the trick! {{{ cc1: error: unrecognized command line option "-fno-unit-at-atime" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:39:42 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:32:11 2008 Subject: [GHC] #2343: Docs are installed to a peculiar location In-Reply-To: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> References: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> Message-ID: <051.2b914ac4ba3a01231e5d179948b8c0b6@localhost> #2343: Docs are installed to a peculiar location ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Comment (by bos): I've attached the build instructions as `ghc.spec` and the log as `rpmbuild.out.bz2`. You can see the commands being executed in the log file by searching for lines beginning with "`+ `". The `build.mk` file is simple: {{{ cat <> mk/build.mk docdir := %{_docdir}/%{name}-%{version} htmldir := $(docdir) dvidir := $(docdir) pdfdir := $(docdir) psdir := $(docdir) HADDOCK_PATH_HACK }}} This hackery was necessary under ghc 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:44:45 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:37:14 2008 Subject: [GHC] #1061: default class methods can be given too general a type as GHC tries to share them between instances In-Reply-To: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> References: <044.844f66ca4a26056df0ffe2da43b8e56b@localhost> Message-ID: <053.3f9c66a8cbb00391d4daee3ea38828f7@localhost> #1061: default class methods can be given too general a type as GHC tries to share them between instances ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tc199 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): See also #1624 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 09:46:09 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 09:38:38 2008 Subject: [GHC] #1624: internal error caused by adding an instance to a type class with a functional dependency and a default method In-Reply-To: <044.cc337884807f671e60befdf4b9228967@localhost> References: <044.cc337884807f671e60befdf4b9228967@localhost> Message-ID: <053.69959ed42d9d8e9349e95f215d87015a@localhost> #1624: internal error caused by adding an instance to a type class with a functional dependency and a default method -------------------------------------+-------------------------------------- Reporter: int-e | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1624 | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * testcase: => T1624 * status: new => closed * resolution: => fixed Comment: Actually this one is fixed as a result of fixing #1061. In the case of default methods we should not really type-check the default method instance, which is what gave rise to the error above. Happy days. The test is in `typecheck/should_run/T1624.hs`. It'll be released in 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 10:08:41 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 10:01:10 2008 Subject: [GHC] #2343: Docs are installed to a peculiar location In-Reply-To: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> References: <042.c245d6b9f30b397298f5cdd03080b79f@localhost> Message-ID: <051.eea54b704c63167fc67acc95291e014d@localhost> #2343: Docs are installed to a peculiar location ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: The problem is that this was generating `mk/build.mk` containing: {{{ docdir := /usr/share/doc/ghc-6.8.2.20080603 htmldir := dvidir := pdfdir := psdir := }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 12:12:14 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 12:04:43 2008 Subject: [GHC] #2350: hSetEcho: failed (failed to set echoing) on Windows In-Reply-To: <046.f635148d87eda19915274a731d766966@localhost> References: <046.f635148d87eda19915274a731d766966@localhost> Message-ID: <055.dfde5e1dff1ebc492a3678fdcef67570@localhost> #2350: hSetEcho: failed (failed to set echoing) on Windows -------------------------------+-------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Changes (by EricKow): * status: new => closed * resolution: => invalid Comment: Oops! It occured to me that I was supposed to set echo on stdin, not on stdout (I guess)... program seems to work fine without it. Sorry! I guess I'll just resolve this as invalid? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 12:37:00 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 12:29:50 2008 Subject: [GHC] #2351: NetBSD defines ELF_ST_TYPE Message-ID: <043.48a409a4ca4cc55c3e518b567c9a2f02@localhost> #2351: NetBSD defines ELF_ST_TYPE -------------------------------+-------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: NetBSD -------------------------------+-------------------------------------------- NetBSD 4.0 defines ELF_ST_TYPE and ELF_ST_BIND already, so these definitions for x86_64 in rts/Linker.c should be conditional on non- existence,as they are for i386, not just conditional on not-FreeBSD. --- rts/Linker.c.dist 2008-06-03 10:21:22.000000000 -0700 +++ rts/Linker.c 2008-06-05 17:01:11.000000000 -0700 @@ -2612,10 +2612,16 @@ #define Elf_Sym Elf64_Sym #define Elf_Rel Elf64_Rel #define Elf_Rela Elf64_Rela -#if !defined(freebsd_HOST_OS) +#ifndef ELF_ST_TYPE #define ELF_ST_TYPE ELF64_ST_TYPE +#endif +#ifndef ELF_ST_BIND #define ELF_ST_BIND ELF64_ST_BIND +#endif +#ifndef ELF_R_TYPE #define ELF_R_TYPE ELF64_R_TYPE +#endif +#ifndef ELF_R_SYM #define ELF_R_SYM ELF64_R_SYM #endif #else -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 13:15:54 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 13:08:33 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.334300b8a6a4affcba959b19fd42aaa9@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: I've applied a rather hacky fix to the 6.8 branch, but this'll probably need fixing in the HEAD too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 17:40:00 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 17:32:50 2008 Subject: [GHC] #2348: x86_64-unknown-netbsd can be a supported platform In-Reply-To: <043.0c34f3aad4366c5bfad8c45429c61dd1@localhost> References: <043.0c34f3aad4366c5bfad8c45429c61dd1@localhost> Message-ID: <052.2fc96b04f6e094aa7cadc694dd36c4ee@localhost> #2348: x86_64-unknown-netbsd can be a supported platform --------------------------+------------------------------------------------- Reporter: donn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Old description: > The top level configure.ac should include x86_64-unknown-netbsd as a > supported platform. The case branch can be identical to x86_64-unknown- > freebsd, etc., mutatis mutando: > > --- configure.ac.dist 2008-06-03 10:21:17.000000000 -0700 > +++ configure.ac 2008-06-04 18:28:37.000000000 -0700 > @@ -161,6 +161,15 @@ > HostVendor_CPP='unknown' > HostOS_CPP='openbsd' > ;; > +amd64-*-netbsd*|x86_64-*-netbsd*) > + HostPlatform=x86_64-unknown-netbsd > + TargetPlatform=x86_64-unknown-netbsd > + BuildPlatform=x86_64-unknown-netbsd > + HostPlatform_CPP='x86_64_unknown_netbsd' > + HostArch_CPP='x86_64' > + HostVendor_CPP='unknown' > + HostOS_CPP='netbsd' > + ;; > amd64-*-freebsd*|x86_64-*-freebsd*) > HostPlatform=x86_64-unknown-freebsd > TargetPlatform=x86_64-unknown-freebsd New description: The top level configure.ac should include x86_64-unknown-netbsd as a supported platform. The case branch can be identical to x86_64-unknown- freebsd, etc., mutatis mutando: {{{ --- configure.ac.dist 2008-06-03 10:21:17.000000000 -0700 +++ configure.ac 2008-06-04 18:28:37.000000000 -0700 @@ -161,6 +161,15 @@ HostVendor_CPP='unknown' HostOS_CPP='openbsd' ;; +amd64-*-netbsd*|x86_64-*-netbsd*) + HostPlatform=x86_64-unknown-netbsd + TargetPlatform=x86_64-unknown-netbsd + BuildPlatform=x86_64-unknown-netbsd + HostPlatform_CPP='x86_64_unknown_netbsd' + HostArch_CPP='x86_64' + HostVendor_CPP='unknown' + HostOS_CPP='netbsd' + ;; amd64-*-freebsd*|x86_64-*-freebsd*) HostPlatform=x86_64-unknown-freebsd TargetPlatform=x86_64-unknown-freebsd }}} Comment: Applied to HEAD and 6.8 branch, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 17:40:38 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 17:33:08 2008 Subject: [GHC] #2347: x86_64-*-netbsd can be added to mangler target platforms In-Reply-To: <043.a54819edde4ee1170c8d5536df6e4a3c@localhost> References: <043.a54819edde4ee1170c8d5536df6e4a3c@localhost> Message-ID: <052.f2a044e73bc7408f078f5ca361c1eaa4@localhost> #2347: x86_64-*-netbsd can be added to mangler target platforms --------------------+------------------------------------------------------- Reporter: donn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied to HEAD and 6.8 branch, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 17:41:15 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 17:33:55 2008 Subject: [GHC] #2312: object splitting is not done under sparc solaris with gcc-4.2.2 In-Reply-To: <045.9cbac76e1c456715b62972e331893bc6@localhost> References: <045.9cbac76e1c456715b62972e331893bc6@localhost> Message-ID: <054.5aef9033530ce1478ae851fb5d60f814@localhost> #2312: object splitting is not done under sparc solaris with gcc-4.2.2 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, great, should work in 6.8 branch and HEAD now, then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:05:41 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 18:58:13 2008 Subject: [GHC] #2260: Non-ideal error message for misplaced LANGUAGE pragma In-Reply-To: <044.7cbacc8885ebc555467b0dece9c1a57d@localhost> References: <044.7cbacc8885ebc555467b0dece9c1a57d@localhost> Message-ID: <053.3c900ec6219960cc74a5ff4d0157a80d@localhost> #2260: Non-ideal error message for misplaced LANGUAGE pragma -------------------------------+-------------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: That's a good idea, although sadly not quite as easy to implement right as you might imagine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:08:40 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:01:10 2008 Subject: [GHC] #2261: Foreign.C.Error.Errno should be an instance of (Eq, Ord, Show... others?) In-Reply-To: <044.d2c4495f54736a05cc5accbccdb5e35e@localhost> References: <044.d2c4495f54736a05cc5accbccdb5e35e@localhost> Message-ID: <053.2bc6e7ef5d29c6d78fede6e1610947c2@localhost> #2261: Foreign.C.Error.Errno should be an instance of (Eq,Ord, Show... others?) ----------------------------+----------------------------------------------- Reporter: TomMD | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: trivial | Resolution: wontfix Keywords: Foreign, Errno | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Please use http://www.haskell.org/haskellwiki/Library_submissions if you want to propose this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:21:06 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:13:36 2008 Subject: [GHC] #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 In-Reply-To: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> References: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> Message-ID: <056.988ddedbe5b70465eb86f567aba3324b@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 ----------------------+----------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:24:20 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:16:49 2008 Subject: [GHC] #2266: validate requires haddock to be installed In-Reply-To: <050.c15637911c8b86321b0fb91e30218ecb@localhost> References: <050.c15637911c8b86321b0fb91e30218ecb@localhost> Message-ID: <059.448456a3c23e64d6c66f2e8222d9f11a@localhost> #2266: validate requires haddock to be installed -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: This is a bit fiddly - it's Cabal that finds haddock, so it's hard to know if it will succeed or not. Maybe we should detect it ourselves instead, and tell Cabal where to find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:25:31 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:18:00 2008 Subject: [GHC] #2272: internal error: getMBlock: mmap: Bad file number In-Reply-To: <044.485296ba49fdd540ac589cc1c46011fb@localhost> References: <044.485296ba49fdd540ac589cc1c46011fb@localhost> Message-ID: <053.e750680cfedd5145cc8d9b2348651111@localhost> #2272: internal error: getMBlock: mmap: Bad file number ----------------------+----------------------------------------------------- Reporter: hpwei | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > I cut and paste the code from > http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in- > haskell > > And compiled the resulting portscan.hs > with both ghc-6.8.2 and ghc-6.6.1 > on a host with Sun-Sparc [SunOS 5.10]. > > The following error occurred when the code was invoked. > > portscan a_remote_sun_sparc_machine 1 1000 > portscan: internal error: getMBlock: mmap: Bad file number > (GHC version 6.6.1 for sparc_sun_solaris2) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort > > [ note: same result for 6.8.2 ] > > [ note: if the remote machine is a linux machine, then the code works. ] > > --HP New description: I cut and paste the code from http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in- haskell And compiled the resulting portscan.hs with both ghc-6.8.2 and ghc-6.6.1 on a host with Sun-Sparc [SunOS 5.10]. The following error occurred when the code was invoked. {{{ portscan a_remote_sun_sparc_machine 1 1000 portscan: internal error: getMBlock: mmap: Bad file number (GHC version 6.6.1 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort }}} [ note: same result for 6.8.2 ] [ note: if the remote machine is a linux machine, then the code works. ] --HP -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:34:25 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:26:56 2008 Subject: [GHC] #2275: Poor indication of type error location In-Reply-To: <044.43d81bf78db38afe22fab3304ba5b342@localhost> References: <044.43d81bf78db38afe22fab3304ba5b342@localhost> Message-ID: <053.c881f6e00aefb4d454e2756fc54f6a72@localhost> #2275: Poor indication of type error location -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * priority: normal => low * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 6 19:40:27 2008 From: trac at galois.com (GHC) Date: Fri Jun 6 19:32:57 2008 Subject: [GHC] #2278: Inconsistent behaviour between -odir and -hidir options In-Reply-To: <044.da2157b8bb277561bb6fe2b75576c141@localhost> References: <044.da2157b8bb277561bb6fe2b75576c141@localhost> Message-ID: <053.5bb1f305ae34538b2ef81b34f48207ba@localhost> #2278: Inconsistent behaviour between -odir and -hidir options ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Good point, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 7 01:00:04 2008 From: trac at galois.com (GHC) Date: Sat Jun 7 00:53:01 2008 Subject: [GHC] #2352: POSIX.1 unsetenv returns int Message-ID: <043.9a1a67d0fcfde818f197866387595049@localhost> #2352: POSIX.1 unsetenv returns int -------------------------------+-------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: NetBSD -------------------------------+-------------------------------------------- While plenty of C libraries declare void unsetenv(), the POSIX.1003.1 standard is int unsetenv(), with return values 0 or -1. In the latter case, errno is set to EINVAL, for causes including the present of "=" in the value. Of course this is not of earthshaking importance. The following is the autoconf test (just a copy of the same test for usleep().) --- libraries/unix/configure.ac.dist 2008-06-03 10:39:45.000000000 -0700 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700 @@ -75,6 +75,19 @@ ;; esac +### POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older implementations +### in common use return void. +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type, + [AC_EGREP_HEADER(changequote(<, >)changequote([, ]), + /usr/include/stdlib.h, + [cv_func_unsetenv_return_type=void], + [cv_func_unsetenv_return_type=int])]) +case "$cv_func_unsetenv_return_type" in + "void" ) + AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares unsetenv to return void.]) + ;; +esac + dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to set AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) AC_EGREP_CPP(yes, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 7 08:14:22 2008 From: trac at galois.com (GHC) Date: Sat Jun 7 08:06:59 2008 Subject: [GHC] #2353: GHC inliner doesn't Message-ID: <044.0a130fadcfff13182791f64ebade3181@localhost> #2353: GHC inliner doesn't ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Compile this program {{{ {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Foo where class C a where to' :: a -> Int from' :: Int -> a {-# NOINLINE to #-} to :: (C a) => a -> Int to = to' {-# NOINLINE from #-} from :: (C a) => Int -> a from = from' {-# INLINE foo #-} foo :: (C a) => (Int -> Int) -> a -> a foo f x = from (f (to x)) bar :: (C a) => (Int -> Int) -> a -> a bar f = foo f . foo f }}} Study the output. It contains {{{ ... Foo.foo = __inline_me (\ (@ a_a6n) ($dC_a6t :: Foo.C a_a6n) -> ... }}} and {{{ ... Foo.bar = \ (@ a_a6w) ($dC_a6G :: Foo.C a_a6w) -> let { foo1_s7S [ALWAYS Just L] :: (GHC.Base.Int -> GHC.Base.Int) -> a_a6w -> a_a6w [Str: DmdType] foo1_s7S = Foo.foo @ a_a6w $dC_a6G ... }}} Why isn't foo inlined? Note that if the export list is changed to only export bar, then foo does get inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 7 08:30:51 2008 From: trac at galois.com (GHC) Date: Sat Jun 7 08:23:28 2008 Subject: [GHC] #2354: NOINLINE pragma ignored Message-ID: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> #2354: NOINLINE pragma ignored ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Compile the following program {{{ {-# OPTIONS_GHC -O -ddump-simpl #-} module F(test) where class AsInt a where {-# NOINLINE toInt #-} toInt :: a -> Int {-# NOINLINE fromInt #-} fromInt :: Int -> a {-# INLINE onInt #-} onInt :: AsInt a => (Int -> Int) -> (a -> a) onInt f x = fromInt (f (toInt x)) test :: AsInt a => (Int -> Int) -> (Int -> Int) -> (a -> a) test h g = onInt h . onInt g }}} Look at the final output for test: {{{ F.test = \ (@ a_a6c) ($dAsInt_a6m :: F.AsInt a_a6c) (eta_s6B :: GHC.Base.Int -> GHC.Base.Int) (eta1_s6C :: GHC.Base.Int -> GHC.Base.Int) (eta2_s6D :: a_a6c) -> case $dAsInt_a6m of tpl_B1 { F.:DAsInt tpl1_B2 tpl2_B3 -> tpl2_B3 (eta_s6B (tpl1_B2 (tpl2_B3 (eta1_s6C (tpl1_B2 eta2_s6D))))) }}} The method (selectors) toInt and fromInt have been inlined despite the NOINLINE pragma. The compiler should either obey the pragma, or tell me that I can't have it in that place. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 7 08:39:47 2008 From: trac at galois.com (GHC) Date: Sat Jun 7 08:32:17 2008 Subject: [GHC] #2089: reading the package db is slow In-Reply-To: <045.d775bdf76041d9776497ac4f6a221252@localhost> References: <045.d775bdf76041d9776497ac4f6a221252@localhost> Message-ID: <054.216edbb96c3e2c2f5dd11ca116482ba5@localhost> #2089: reading the package db is slow ------------------------------------------+--------------------------------- Reporter: duncan | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Multiple | ------------------------------------------+--------------------------------- Comment (by duncan): Here is an example from debian where the current ghc-pkg register/unregister system causes excess complexity: https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 The problem is that there are a lot of dependencies on the order in which actions are performed. When upgrading ghc one has to unregister all the old packages, then install the new ghc and then install and register all the new packages. When packages are not written perfectly we end up with corner cases where things go wrong (like the above bug about packages being uninstallable). With the proposed system it would be much simpler. The files could be uninstalled and installed in any old order so long as we `ghc-pkg update` at the end. There are many other examples of similar systems in linux distros, so this mode is reasonably well supported (info caches, font registration, gtk+ icon cache etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 7 14:59:11 2008 From: trac at galois.com (GHC) Date: Sat Jun 7 14:51:43 2008 Subject: [GHC] #2322: cmath library broken with -fvia-C In-Reply-To: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> References: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> Message-ID: <056.9d736b7f70689fc27f4e2d542d0308c0@localhost> #2322: cmath library broken with -fvia-C ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by dons): On a similar note, it breaks the mersenne-random package under ghc head, http://www.haskell.org/pipermail/haskell-cafe/2008-June/044067.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 07:55:37 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:48:02 2008 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks In-Reply-To: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> References: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> Message-ID: <057.28a4ee59d069016d53b31a30edf5b905@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------+---------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 07:59:55 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:52:19 2008 Subject: [GHC] #2286: HGL library do not compile In-Reply-To: <054.4215bab50789703cf266b7917f1289de@localhost> References: <054.4215bab50789703cf266b7917f1289de@localhost> Message-ID: <063.bcce4a291bfae3fc1686030308035369@localhost> #2286: HGL library do not compile -----------------------------+---------------------------------------------- Reporter: rgarciapariente | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/HGL | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > if you try to compile HGL-3.2.0.0 in ghc 6.8.2 on Windows: > > C:\ghc\HGL-3.2.0.0>runghc Setup.hs configure > Configuring HGL-3.2.0.0... > > C:\ghc\HGL-3.2.0.0>runghc Setup.hs build > Preprocessing library HGL-3.2.0.0... > Building HGL-3.2.0.0... > > Graphics/HGL/Key.hs:57:7: > Could not find module `Graphics.Win32': > it is a member of package Win32-2.1.1.0, which is hidden > > But: > > C:\ghc\HGL-3.2.0.0>ghc-pkg list > C:/ghc/ghc-6.8.2\package.conf: > Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, > QuickCheck-1.1.0.0, '''Win32-2.1.1.0''', array-0.1.0.0, base-3.0.1.0, > bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, > directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), > haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, > mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, > packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, > pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, > regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, > rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, > xhtml-3000.0.2.1 New description: if you try to compile HGL-3.2.0.0 in ghc 6.8.2 on Windows: {{{ C:\ghc\HGL-3.2.0.0>runghc Setup.hs configure Configuring HGL-3.2.0.0... C:\ghc\HGL-3.2.0.0>runghc Setup.hs build Preprocessing library HGL-3.2.0.0... Building HGL-3.2.0.0... Graphics/HGL/Key.hs:57:7: Could not find module `Graphics.Win32': it is a member of package Win32-2.1.1.0, which is hidden }}} But: {{{ C:\ghc\HGL-3.2.0.0>ghc-pkg list C:/ghc/ghc-6.8.2\package.conf: Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Win32-2.1.1.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:04:01 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:56:25 2008 Subject: [GHC] #2286: HGL library do not compile In-Reply-To: <054.4215bab50789703cf266b7917f1289de@localhost> References: <054.4215bab50789703cf266b7917f1289de@localhost> Message-ID: <063.056eac61e02316165af558d18324737d@localhost> #2286: HGL library do not compile -----------------------------+---------------------------------------------- Reporter: rgarciapariente | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => Not GHC Comment: When it was a GHC extralib we didn't try to build it on Windows, so I think it's known that it doesn't work. HGL could do with a maintainer if it's still useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:04:01 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:56:28 2008 Subject: [GHC] #2287: GHCi fails to start In-Reply-To: <047.5d53287697af066a4caf4c1cc60cb430@localhost> References: <047.5d53287697af066a4caf4c1cc60cb430@localhost> Message-ID: <056.aaf84c601b2dfee3b23f9a2c4b78cd01@localhost> #2287: GHCi fails to start ----------------------+----------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > GHCi fails to start with following error message: > > : Unknown PEi386 section name `.reloc' (while processing: C:\ghc\ghc-head > \ghc-prim-0.1\HSghc-prim-0.1.o) > Loading package ghc-prim ... : panic! (the 'impossible' happened) > (GHC version 6.9.20080514 for i386-unknown-mingw32): > loadObj: failed > > Both GHC version 6.9.20080514 with build setting "quick" and build > setting "quickest" have this issue. New description: GHCi fails to start with following error message: {{{ : Unknown PEi386 section name `.reloc' (while processing: C:\ghc\ghc-head \ghc-prim-0.1\HSghc-prim-0.1.o) Loading package ghc-prim ... : panic! (the 'impossible' happened) (GHC version 6.9.20080514 for i386-unknown-mingw32): loadObj: failed }}} Both GHC version 6.9.20080514 with build setting "quick" and build setting "quickest" have this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:04:44 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:57:09 2008 Subject: [GHC] #2287: GHCi fails to start In-Reply-To: <047.5d53287697af066a4caf4c1cc60cb430@localhost> References: <047.5d53287697af066a4caf4c1cc60cb430@localhost> Message-ID: <056.a7595d8916d1a0d2e26c7792f463916b@localhost> #2287: GHCi fails to start ----------------------+----------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Thanks for the report, we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:05:17 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 07:57:41 2008 Subject: [GHC] #2291: Panic mixing RULES and Type Families In-Reply-To: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> References: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> Message-ID: <053.74a8d200a3fb3d8588709ace13cd52b0@localhost> #2291: Panic mixing RULES and Type Families ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families, rewrite rules | Difficulty: Unknown Testcase: attached | Architecture: Multiple Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > It appears that RULES pragmas and type families don't always play nice. > > When either of the last two RULES is present, you get an error analogous > to the following. Attempting to supply a manual type annotation did not > help. > > Attached is a simplified test case. > > [1 of 1] Compiling Small ( Small.hs, interpreted ) > ghc-6.9.20080401: panic! (the 'impossible' happened) > (GHC version 6.9.20080401 for i386-unknown-linux): > tcSimplifyRuleLhs > Wanted t_apn{tv} [tau] :: main:Small.Coexp{tc roa} > k{tv apj} [tau] b{tv apm} [tau] c{tv apk} > [tau] > ~ > main:Small.Coexp{tc roa} > k{tv apj} [tau] b{tv apb} [tau] c{tv apc} > [tau] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: It appears that RULES pragmas and type families don't always play nice. When either of the last two RULES is present, you get an error analogous to the following. Attempting to supply a manual type annotation did not help. Attached is a simplified test case. {{{ [1 of 1] Compiling Small ( Small.hs, interpreted ) ghc-6.9.20080401: panic! (the 'impossible' happened) (GHC version 6.9.20080401 for i386-unknown-linux): tcSimplifyRuleLhs Wanted t_apn{tv} [tau] :: main:Small.Coexp{tc roa} k{tv apj} [tau] b{tv apm} [tau] c{tv apk} [tau] ~ main:Small.Coexp{tc roa} k{tv apj} [tau] b{tv apb} [tau] c{tv apc} [tau] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:14:54 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 08:07:18 2008 Subject: [GHC] #2322: cmath library broken with -fvia-C In-Reply-To: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> References: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> Message-ID: <056.e0e0e39076044b89b28250c18b7d8994@localhost> #2322: cmath library broken with -fvia-C ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Replying to [comment:1 dons]: > On a similar note, it breaks the mersenne-random package under ghc head, > > http://www.haskell.org/pipermail/haskell-cafe/2008-June/044067.html This isn't the same thing as far as I can see - the problem isn't caused by GHC's RTS needing to #include a header defining those functions, but because GHC no longer looks at the header files, so doesn't see the `inline static` functions in them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 08:21:48 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 08:14:11 2008 Subject: [GHC] #2291: Panic mixing RULES and Type Families In-Reply-To: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> References: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> Message-ID: <053.f0c24d757bbf0346ce99469428e47586@localhost> #2291: Panic mixing RULES and Type Families ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: type families, rewrite rules | Difficulty: Unknown Testcase: attached | Architecture: Multiple Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Thanks for the report and small testcase! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 09:07:44 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 09:00:08 2008 Subject: [GHC] #2286: HGL library do not compile In-Reply-To: <054.4215bab50789703cf266b7917f1289de@localhost> References: <054.4215bab50789703cf266b7917f1289de@localhost> Message-ID: <063.17836079daa39af7d3999ff5cf06d62d@localhost> #2286: HGL library do not compile -----------------------------+---------------------------------------------- Reporter: rgarciapariente | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by duncan): The only interesting package that depended on HGL was the SOE library and there are now two implementations of SOE that use things other than HGL. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 10:01:29 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 09:53:55 2008 Subject: [GHC] #2296: Functional dependencies error message has no position information In-Reply-To: <051.b7043276a2125146a84a038bd8ef8992@localhost> References: <051.b7043276a2125146a84a038bd8ef8992@localhost> Message-ID: <060.618b9deab517c3883abf2354b4e3d4c2@localhost> #2296: Functional dependencies error message has no position information --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks, we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 10:01:29 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 09:53:56 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.9dab3980dd733b92cc70d6a3769c1875@localhost> #2295: Combined -odir/-hidir flag -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I think we should definitely do something here, although I'm not sure exactly what. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 10:17:14 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 10:09:38 2008 Subject: [GHC] #2298: renameFile is not atomic on Windows In-Reply-To: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> References: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> Message-ID: <054.abf31d3e4749a9d14d12471261565623@localhost> #2298: renameFile is not atomic on Windows ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:07:32 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 10:59:56 2008 Subject: [GHC] #2302: error messages mangle unicode characters In-Reply-To: <044.147efe59df054c7c5210f4aae33a16fd@localhost> References: <044.147efe59df054c7c5210f4aae33a16fd@localhost> Message-ID: <053.21ed572e5c40f85352b0397bbd23d601@localhost> #2302: error messages mangle unicode characters ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:07:51 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:00:14 2008 Subject: [GHC] #2303: unicode: nko characters can't be used in string literals In-Reply-To: <044.70e2afcd767b6042756ff0b013e94c28@localhost> References: <044.70e2afcd767b6042756ff0b013e94c28@localhost> Message-ID: <053.abadc33c96f196377c281ac86a417ea9@localhost> #2303: unicode: nko characters can't be used in string literals -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:10:30 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:02:53 2008 Subject: [GHC] #2304: unicode digits misparsed in escape sequences In-Reply-To: <044.64b9e7c640fc035d36b9efb36b933234@localhost> References: <044.64b9e7c640fc035d36b9efb36b933234@localhost> Message-ID: <053.ae8163319e0fb13e6a44bf709209b8e2@localhost> #2304: unicode digits misparsed in escape sequences -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Parser) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:16:07 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:08:29 2008 Subject: [GHC] #2315: Control.Applicative.ZipList doesn't derive Show In-Reply-To: <046.585e46ba5f67d2dd3e60b3824a844b5a@localhost> References: <046.585e46ba5f67d2dd3e60b3824a844b5a@localhost> Message-ID: <055.6cdd99d702b286107cea4f6888938ba6@localhost> #2315: Control.Applicative.ZipList doesn't derive Show -------------------------------+-------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Please see http://www.haskell.org/haskellwiki/Library_submissions for how to propose library changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:16:42 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:09:05 2008 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads In-Reply-To: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> References: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> Message-ID: <056.859b1c647bb405da4a7187c97f6f97ac@localhost> #2316: Add Applicative instances for all MTL Monads -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:17:37 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:09:59 2008 Subject: [GHC] #2319: STM not as fair as it could be In-Reply-To: <044.81823a3e2ec18990aac9bedd6527630b@localhost> References: <044.81823a3e2ec18990aac9bedd6527630b@localhost> Message-ID: <053.79cc54bfa2f150a77cc5b18c2015d98e@localhost> #2319: STM not as fair as it could be ----------------------------+----------------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Sorry, too late for 6.8.3, but let's try to take a look for 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 11:32:33 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 11:24:59 2008 Subject: [GHC] #2323: Segfaulting binary only with modules In-Reply-To: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> References: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> Message-ID: <052.975e3537bc250d87b764ec6be837d306@localhost> #2323: Segfaulting binary only with modules ----------------------+----------------------------------------------------- Reporter: yrn1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Good testcase, thanks! I can't reproduce the problem on amd64/Linux, but that's not too surprising. It would be useful to know if this is reproducible with PPC/OS X in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 14:30:03 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 14:22:27 2008 Subject: [GHC] #2323: Segfaulting binary only with modules In-Reply-To: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> References: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> Message-ID: <052.d3097c1715e27e1dbfe22a7e2e99bf2b@localhost> #2323: Segfaulting binary only with modules ----------------------+----------------------------------------------------- Reporter: yrn1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): On a {{{ $ uname -a Darwin thorkil-naurs-mac-mini.local 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:51:20 PDT 2008; root:xnu-1228.5.18~1/RELEASE_PPC Power Macintosh }}} (which is a PPC Mac OS X 10.5.3 Leopard), I cannot reproduce this problem with a recent HEAD: {{{ $ /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx- head-2/build/compiler/stage2/ghc-inplace --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080607 $ /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx- head-2/build/compiler/stage2/ghc-inplace --make Main [1 of 2] Compiling Math ( Math.hs, Math.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main 33 }}} For completion, I have verified this using {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 }}} on the same machine and also using {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} on another machine, a PPC Max OS X 10.4.11 Tiger: {{{ $ uname -a Darwin thorkil-naurs-mac-mini.local 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:51:20 PDT 2008; root:xnu-1228.5.18~1/RELEASE_PPC Power Macintosh }}} In no instances have I been able to reproduce this problem. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 17:29:18 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 17:21:42 2008 Subject: [GHC] #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor In-Reply-To: <042.8ec2e257f7876a94d308884cd219f40a@localhost> References: <042.8ec2e257f7876a94d308884cd219f40a@localhost> Message-ID: <051.84186c7cbbf75525b722b7460d940025@localhost> #2329: Control.Parallel.Strategies: definitions of rnf for most collections are poor --------------------------------------+------------------------------------- Reporter: bos | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: I'm not sure exactly what changes you're proposing, if any, or if Ross's reply negates them, but please propose them using http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 17:36:35 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 17:28:58 2008 Subject: [GHC] #2332: Can't allocate 4 gigs of RAM In-Reply-To: <049.b927c02f2fd47c4ea604c4be8f41114f@localhost> References: <049.b927c02f2fd47c4ea604c4be8f41114f@localhost> Message-ID: <058.6652ec37931f8da25fd0551c50d36d99@localhost> #2332: Can't allocate 4 gigs of RAM -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: memory allocation | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.1 Comment: The programs are {{{ import Data.Word import Data.Array.IO import Data.Array import Data.Int main = do a <- newArray_ (0, 2^32-1) :: IO (IOUArray Int Word8) print =<< a `readArray` (2^32-1) return () }}} and {{{ module Main where import Data.Array.IO import Data.Array.Storable import Data.Int import IO buildTable1 :: Int -> IO (IOUArray Int Int8) buildTable1 size = newArray (0,size-1) 0 buildTable2 :: Int -> IO (StorableArray Int Int8) buildTable2 size = newArray (0,size-1) 0 go arr = do str <- getLine val <- readArray arr (read str) print val writeArray arr (read str) (val+1) go arr --size = 4294967296 -- 4 * 2^30 (too big) --size = 4294907296 -- Main: internal error... size = 4290967296 -- works main = do hSetBuffering stdout NoBuffering print $ ("Building table...",size) arr <- buildTable2 size putStrLn "" putStrLn "Ready." go arr }}} Giving it to you, Simon, as I think you have or will have a machine with enough RAM to try to reproduce it! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 8 17:40:25 2008 From: trac at galois.com (GHC) Date: Sun Jun 8 17:32:47 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.5e1c81f6ad3037a056df5196c8a52dae@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the heads-up, we'll look into what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 04:02:43 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 03:55:11 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.92231234fc183b7d2a60c29cde4512b9@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: GHC deliberately doesn't inline a function, even if there's an INLINE pragma, if there is nothing "interesting" about the arguments or context. For example {{{ f x y = g (h x y) }}} Here GHC won't inline `h` even if `h` has an INLINE pragma. Why? Because doing so just increases code duplication. However, GHC does take account of context too. If `g` has a RULE, then `h` will be inlined in case that inlining allows g's RULE to match. It's possible that even this isn't enough in some circumstances. Perhaps you have such a case in mind. But as things stand, it's deliberate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 05:27:04 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 05:19:34 2008 Subject: [GHC] #2354: NOINLINE pragma ignored In-Reply-To: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> References: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> Message-ID: <053.2b89b36205085948fd3cf92ffe254673@localhost> #2354: NOINLINE pragma ignored ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Yes, I agree this is surprising, and arguably wrong. However, a difficulty is that it's not clear what this might mean: {{{ class AsInt a where {-# INLINE toInt #-} toInt :: a -> Int toInt x = }}} Now, does the INLINE pragma apply to the ''method selector'' (which picks the method from the dictionary record) or to the ''default method''n (used in instance decls when no specific method is supplied)? Or both, perhaps? I think GHC assumes the latter at the moment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 05:53:03 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 05:45:25 2008 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost> References: <047.a1f2675dc59d934ab527e6234630f65b@localhost> Message-ID: <056.dc4f418954c69b54e035d8eaf830eeb7@localhost> #1880: Unify flag descriptions to generate both docs and code ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): something has gone wrong here, with all the ticket splitting and closing. it seems that recent ghcs support neither `--print-docdir` nor anything resembling `--full-flag-help`. since i tend to work with multiple self-compiled ghcs more than with installer versions, i'm still looking mainly for something commandline based, exactly what the original #1226 tried to address. at this stage, since my patch for #1226 was rejected, i'd be happy with a minimal solution, with `ghc --full-flag-help` - calling `man ` where available (including cygwin) - do its own man-to-text conversion where `man` is not available; or reply with the path to the version-specific flag reference html page (then i could write a wrapper to start a browser with this) (commandline output preferred, of course..) btw, what happened to `--print-docdir`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 07:22:31 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 07:14:53 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 Message-ID: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> #2355: Building NDP fails with GHC panic on x86_64 -------------------------------+-------------------------------------------- Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: ndp ghc panic | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- With the latest GHC and NDP from darcs I get the following during the compilation of NDP on my Intel Core 2 Quad (x86_64) system: {{{ [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( Data/Array/Parallel/Base/Rebox.hs, dist/build/Data/Array/Parallel/Base/Rebox.o ) ghc-6.9.20080605: panic! (the 'impossible' happened) (GHC version 6.9.20080605 for x86_64-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is what I did to get to that point: {{{ $ darcs get --partial http://darcs.haskell.org/ghc $ cd ghc $ chmod a+x darcs-all $ ./darcs-all get }}} I then copied mk/build.mk.sample to mk/build.mk, uncommenting the line "{{{BuildFlavour = perf}}}", after which: {{{ $ sh boot $ ./configure $ make $ cd libraries $ darcs get http://darcs.haskell.org/packages/ndp/ $ make make.library.ndp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 09:06:14 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 08:58:37 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.a9bb149a7b45a4a4d707d4406bdd901f@localhost> #2355: Building NDP fails with GHC panic on x86_64 -------------------------------+-------------------------------------------- Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: ndp ghc panic | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by Nolari): Having found out about the http://darcs.haskell.org/ghc-2008-06-02/ branch I decided to give that a go. That got me a bit further along, but a panic still occurs in a different place: {{{ [16 of 78] Compiling Data.Array.Parallel.Stream.Segmented ( Data/Array/Parallel/Stream/Segmented.hs, dist/build/Data/Array/Parallel/Stream/Segmented.p_o ) GHC error in desugarer lookup in ndp:Data.Array.Parallel.Stream.Segmented: attempting to use module `ndp:Data.Array.Parallel.Lifted.PArray' (./Data/Array/Parallel/Lifted/PArray.hs) which is not loaded ghc-6.9.20080602: panic! (the 'impossible' happened) (GHC version 6.9.20080602 for x86_64-unknown-linux): initDs user error (IOEnv failure) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 11:05:41 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 10:58:14 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.6bad40aef1d4dab5ae02734a4403cf1d@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): If it is deliberate, why does exporting foo make a difference? That's rather unintuitive. I'm not sure I buy that argument that not inlining foo is the right decision here. Look at the difference in code without and with inlining. I think the inlined version looks better. {{{ -- No inline Foo.bar = \ (@ a_a6v) ($dC_a6F :: Foo.C a_a6v) -> let { foo1_s7R [Just L] :: (GHC.Base.Int -> GHC.Base.Int) -> a_a6v -> a_a6v [Str: DmdType] foo1_s7R = Foo.foo @ a_a6v $dC_a6F } in \ (f_a5Y :: GHC.Base.Int -> GHC.Base.Int) -> let { f1_s7T [Just L] :: a_a6v -> a_a6v [Str: DmdType] f1_s7T = foo1_s7R f_a5Y } in \ (x_a6R :: a_a6v) -> f1_s7T (f1_s7T x_a6R) -- Inline (because foo was not exported) Foo.bar = \ (@ a_a6v) ($dC_a6F :: Foo.C a_a6v) -> let { from1_s7I [Just L] :: GHC.Base.Int -> a_a6v [Str: DmdType] from1_s7I = Foo.from @ a_a6v $dC_a6F } in let { to1_s7G [Just L] :: a_a6v -> GHC.Base.Int [Str: DmdType] to1_s7G = Foo.to @ a_a6v $dC_a6F } in \ (f_a5Y :: GHC.Base.Int -> GHC.Base.Int) (eta_s6T :: a_a6v) -> from1_s7I (f_a5Y (to1_s7G (from1_s7I (f_a5Y (to1_s7G eta_s6T))))) }}} Also, if INLINE doesn't really inline, then I'd like a REALLYINLINE pragma. Sometimes I know what I'm doing, and I'd like the compiler to obey. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 11:08:03 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 11:00:30 2008 Subject: [GHC] #2354: NOINLINE pragma ignored In-Reply-To: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> References: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> Message-ID: <053.1eaacc031d39b167077c155b491a234c@localhost> #2354: NOINLINE pragma ignored ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): Good point. So there should be some way to ask for the method selector not to be inlined. And when there is no default method, then asking for it not to be inlined should probably be an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 11:22:08 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 11:14:29 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.82f1b9c359a5cfa5ee1e9b2d60d9b003@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Always use `dcore-lint`; you often get more informative messages that way. And if you have made any significant change, make sure you start from clean. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 11:53:38 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 11:46:10 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.6e95ab2aea5b1a2e5cc1dc918f1e202f@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): Add the rule below to the example above. With the code as given above the rule doesn't fire since foo isn't inlined. With just bar exported the rule does fire, because foo is inlined. {{{ -- XXX Add -fno-method-sharing to the command line. It's a static flag. :( {-# RULES "to/from" forall x . to (from x) = x #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 11:57:11 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 11:49:41 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.71d3d258c7bcd252836fbedf84b65488@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): A function that is only called once (and not exported) is always inlined, since that causes no code duplication. Does that explain the difference. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 12:01:56 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 11:54:20 2008 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.3f048a4d4a3fda3fdd0aa229840250a5@localhost> #1136: High memory use when compiling many let bindings. ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by simonpj): This patch should help {{{ Thu Jun 5 05:44:23 PDT 2008 simonpj@microsoft.com * Desugar multiple polymorphic bindings more intelligently }}} But I suspect there is something else going on too in the typechecker, perhaps chains of mutable variables. But first let's see if there's any improvement. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 12:13:47 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 12:06:24 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.f739bc5ef9ef1a7e13474856c86d4a3e@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): As you can see, the original program uses foo twice, so that doesn't explain the inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 12:48:22 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 12:40:49 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.69b8e5f8088b291df4b2ebe25bd1c74a@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): Yes, but as you point out, the "method-sharing" thing commons up the two occurrences of 'foo'. If we export foo, we get {{{ Foo.bar = \ (@ a_a6x) ($dC_a6H :: Foo.C a_a6x) -> let { foo1_s7T [ALWAYS Just L] :: (GHC.Base.Int -> GHC.Base.Int) -> a_a6x -> a_a6x [Str: DmdType] foo1_s7T = Foo.foo @ a_a6x $dC_a6H } in \ (f_a60 :: GHC.Base.Int -> GHC.Base.Int) -> let { f1_s7V [ALWAYS Just L] :: a_a6x -> a_a6x [Str: DmdType] f1_s7V = foo1_s7T f_a60 } in \ (x_a6T :: a_a6x) -> f1_s7V (f1_s7V x_a6T) }}} Notice just one call to `foo`. If `foo` is not exported, this is the ''only'' call to `foo` so it gets inlined. It's delicate, I grant you. Maybe I should experiment with making INLINE inline always (at least if saturated). I'm a bit reluctant to further complicate the interface with REALLYINLINE. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 14:05:12 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 13:57:48 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.8302fb56c0912b9705e2c38829d2e475@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): In this case you need to inline foo, and then there will be a second opportunity to inline foo inside the inlined body. It's the first and second inlining of foo that meet in the rule. This indicates that current heuristic for not inlining is broken. I don't really want REALLYINLINE either, but in this case inlining must happen for the rule to apply, so there has to be a way to make the compiler obey the pragma. As you say, it's delicate. Far too delicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 16:06:56 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 15:59:26 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.c12940ff4a867608225414d55ec98960@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by Isaac Dupree): IIRC, one can use RULES (and duplicate the function implementation) as a inline-for-sure equivalent. Not very pleasant, obviously. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 18:41:00 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 18:33:42 2008 Subject: [GHC] #2213: Confusing flags for rewrite rules In-Reply-To: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> References: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> Message-ID: <052.844f0a1f2e58d9f2462e9980b9c6138c@localhost> #2213: Confusing flags for rewrite rules -----------------------------+---------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, warnings | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by claus): * keywords: => rules, warnings * cc: rules, warnings (removed) * cc: claus (added) Comment: i ran into `-frewrite-rules` here: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-June/014912.html the (slightly incorrectly) observed behaviour is *very* confusing: * `-frewrite-rules` on its own is not sufficient to enable `RULES`, presumably because they are discarded before they could be enabled * `-fglasgow-exts` on its own is sufficient, presumably because `-O` implied `-frewrite-rules` anyway imho, wanting `RULES` to be applied implies wanting them to be parsed, not discarded, so `-frewrite-rules` should imply all relevant language flags. until that is the case, the odd dependency should be documented in the flag reference. btw, i changed the odd `cc`, moving `rules, warnings` to keywords. or do these exist as `cc`s? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 9 22:00:20 2008 From: trac at galois.com (GHC) Date: Mon Jun 9 21:52:41 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.09f9d77bfed315103c2e0da29932c221@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Comment (by rl): I'm getting the initC error, too. This module isn't NDP-specific (and isn't vectorised) so it looks like a GHC bug. I guess it's been introduced by Thu Jun 5 05:44:23 PDT 2008 simonpj@microsoft.com * Desugar multiple polymorphic bindings more intelligently since adding -fno-ds-multi-tyvar fixes it. -dcore-lint says: *** Core Lint Errors: in result of Simplifier phase gentle, iteration 1 out of 10 *** : In the expression: Data.Array.Parallel.Base.Rebox.:DRebox @ (Data.Array.Parallel.Base.Rebox.Box a_adV) (rebox_siX @ a_adV) rebox_siX is out of scope Simon, could you please take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 08:25:28 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 08:17:44 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules Message-ID: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> #2356: GHC accepts multiple instances for the same type in different modules ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- as mentioned by Simon PJ in this thread: http://www.haskell.org/pipermail/haskell/2008-June/020436.html here is the example, spelled out: {{{ module B0 where class C a where c :: a -> String data T = T deriving Show module B1 where import B0 instance C T where c _ = "B1" b = c T module B2 where import B0 instance C T where c _ = "B2" b = c T module Main where import B1 import B2 main = print (B1.b,B2.b) }}} this is accepted without flags or errors and prints `("B1","B2")`. the [http://haskell.org/onlinereport/decls.html#sect4.3.2 language report, section 4.3.2] clearly states: A type may not be declared as an instance of a particular class more than once in the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 10:31:17 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 10:23:33 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.f0668ca0b36dea306c7dcf76e7bee123@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: igloo => Comment: I think that the problem is that haddock would be able to see the docs (which live in `base:GHC.Arr`) when compiling `base:Data.Array`, but now that it compiles `array:Data.Array` it can no longer see them. We should fix this somehow if possible; one way might be to just move `GHC.Array` into the `array` package; I don't know how feasible that is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 12:46:06 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 12:38:23 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.cfd45dc1a327db0fdf8b551e94907b3c@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Comment (by simonpj): Sorry about that. It turned out to be a subtle simplifier scoping bug, triggered by the desugarer changes, which meant it took a while to find. I have a patch, but I have not had time to validate it, and I'm about to go away. For now, just use -fno-ds-multi-tyvar Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 15:26:45 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 15:19:15 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.1871bd45749f4184292175984c0dcd0f@localhost> #2356: GHC accepts multiple instances for the same type in different modules -------------------------+-------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by guest): * cc: lennart@augustsson.net (added) Comment: This really surprises me. Why doesn't think produce a link error? Each instance declaration should give rise to a global symbol uniquely determined by the class and the type, I'd presume. And when they meet there will be a clash. Obviously I'm wrong, as this (scary) example shows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 18:37:21 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 18:29:40 2008 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost> References: <047.a1f2675dc59d934ab527e6234630f65b@localhost> Message-ID: <056.ad601758aba4f9a1ffb89e3873082c02@localhost> #1880: Unify flag descriptions to generate both docs and code ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): FYI: {{{ commit 6f50d204c87144cacfee4d86463b2167e34fe6d4 Author: Ian Lynagh Date: Tue Nov 27 20:56:05 2007 +0100 Remove the --print-docdir flag It wasn't doing the right thing for bindists. Let's rethink... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 18:40:14 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 18:32:29 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.5b8953ccc783353993f281fae85dafb1@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): Haddock 2 will fix this, as I understand it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 19:29:50 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 19:22:05 2008 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost> References: <047.a1f2675dc59d934ab527e6234630f65b@localhost> Message-ID: <056.79892048bd5eb40ade5f6ff03b2f78e8@localhost> #1880: Unify flag descriptions to generate both docs and code ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): ah, so it is the general "how do i find the other parts of myself" issue, once again? how about this approach: have `ghc/ghci`, `libdir`, `docdir`, and whatever else is needed, registered as special "system" packages (or as fields of a single system package) with `ghc-pkg` during installation (or post-"install" for tarballs). then the only thing one needs to know is how to find `ghc-pkg` or its database, which `ghc`, `ghci`, and `ghc-pkg` seem to be able to do already. and `ghc-pkg` could be queried for all other tool and library locations. after something like `ghc-pkg register --system docdir `, `ghc-pkg --system docdir` would yield the last registered location of the docs, if any. and similarly for finding libdir, etc. the registration/update would be done by installers, package managers, or users (for tarballs/bootstraps). does that sound plausible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 20:13:22 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:05:41 2008 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost> References: <047.a1f2675dc59d934ab527e6234630f65b@localhost> Message-ID: <056.f8c2a3f82c299ae2a00f01805b96432e@localhost> #1880: Unify flag descriptions to generate both docs and code ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): I think we're getting off-topic. As I understand it, this ticket is about generating all the flags related features (code and docs) from one description not about ghc knowing where someone installed the user guide. If that is on topic then I'd add that I don't actually see what problem `ghc --print-docdir` is solving. Afaik, no other program has such a thing. I'd also like to add a plug for command line flag name completion. We've added that feature in `cabal-install` and it's enormously helpful. It saves typing but most importantly saves having to remember a lot of flag names. With a little support in ghc itself the scripts for bash or other standard shells become pretty trivial. Eg the `cabal` program has a `--list-options` flag which prints each flag, one per line. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 20:50:36 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:42:53 2008 Subject: [GHC] #1315: System.Process.runInteractiveProcess needs a way to pipe just some handles In-Reply-To: <047.139ca64210a2aab1a9c55840d3b1952c@localhost> References: <047.139ca64210a2aab1a9c55840d3b1952c@localhost> Message-ID: <056.a5c10c6dd8c571e0521fd428defee220@localhost> #1315: System.Process.runInteractiveProcess needs a way to pipe just some handles -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The new `System.Process` API has this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:02:39 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:54:55 2008 Subject: [GHC] #592: signal handlers should be able to access siginfo_t information In-Reply-To: <047.44a80ef10278cacddbca83ff583da267@localhost> References: <047.44a80ef10278cacddbca83ff583da267@localhost> Message-ID: <056.754b5a7eb5f5e1044c832a84d26e5aa7@localhost> #592: signal handlers should be able to access siginfo_t information -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/unix | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): See also #1520 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:03:15 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:55:30 2008 Subject: [GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager In-Reply-To: <047.70e7b79651c491b5b253718c9a075059@localhost> References: <047.70e7b79651c491b5b253718c9a075059@localhost> Message-ID: <056.3be0cbd1b46692c0295c11581479397e@localhost> #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by simonmar): See also #592 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:04:13 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:56:30 2008 Subject: [GHC] #1558: make the testsuite work with THREADS=2 In-Reply-To: <047.86273a610439c0814c0caa79ac522fd9@localhost> References: <047.86273a610439c0814c0caa79ac522fd9@localhost> Message-ID: <056.108668a62df48a9f2ddec6f02a8c1252@localhost> #1558: make the testsuite work with THREADS=2 ------------------------+--------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Test Suite | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:07:20 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 20:59:35 2008 Subject: [GHC] #1604: Coarse-grained recompilation checking In-Reply-To: <047.25e3f5167d8cd0b411e4ba1edd811037@localhost> References: <047.25e3f5167d8cd0b411e4ba1edd811037@localhost> Message-ID: <056.de1eeb77a26da29f4387c8a967aea2f4@localhost> #1604: Coarse-grained recompilation checking ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: I decided not to do this: it was easier to convert the existing recompilation checker to use fingerprints, and at the same time audit it to look for bugs (I did find a couple). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:18:11 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 21:10:28 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.cb9a5611b514c421efc85dee8aff83a9@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:31:47 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 21:24:03 2008 Subject: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings Message-ID: <047.95a1ebaf86eb581f2f41f8ae61094ccc@localhost> #2357: Implement the Haskell' proposal for polymorphic pattern bindings ----------------------------------------+----------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- After discussion on the Haskell' mailing list, it was decided that Haskell' will keep polymorphic pattern bindings, with static semantics defined by a translation. [http://hackage.haskell.org/trac/haskell- prime/wiki/SpecifyPatternBindingSemantics] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 10 21:34:03 2008 From: trac at galois.com (GHC) Date: Tue Jun 10 21:26:34 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values In-Reply-To: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> References: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> Message-ID: <054.99d03364ee0a0bcc1e6acc6daee77237@localhost> #2187: Top-level bindings are broken for polymorphic values ----------------------+----------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: major | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: So GHC is behaving "correctly" here, although for Haskell' we've decided to do things differently; see #2357. Hopefully we'll be able to implement the change for 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 11 04:22:01 2008 From: trac at galois.com (GHC) Date: Wed Jun 11 04:14:17 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.6f64a485ec3e0c01e3689ee6a2b70d92@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by japple): Haddock 2 will fix this, as I understand it. Actually, it seems even worse. See http://code.haskell.org/~fons/libraries .html-haddock2.tgz, found at ticket:2299. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 11 04:33:44 2008 From: trac at galois.com (GHC) Date: Wed Jun 11 04:25:59 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.09271afe746b4f159dbdcccee049231a@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by ross): We really need a bug tracker for Haddock2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 11 06:36:08 2008 From: trac at galois.com (GHC) Date: Wed Jun 11 06:28:23 2008 Subject: [GHC] #2287: GHCi fails to start In-Reply-To: <047.5d53287697af066a4caf4c1cc60cb430@localhost> References: <047.5d53287697af066a4caf4c1cc60cb430@localhost> Message-ID: <056.ecc13a06f3585379463e62987321f9ca@localhost> #2287: GHCi fails to start ----------------------+----------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by igloo): The quickest setting works for me. Can you describe exactly how you are building GHC, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 11 06:40:56 2008 From: trac at galois.com (GHC) Date: Wed Jun 11 06:33:11 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.41fd471a202c45044d48cb103325cb26@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Comment (by Nolari): It's not clear to me how to build NDP with `-dcore-lint` turned on (or `-fno-ds-multi-tyvar` for that matter). I tried fiddling with the `Makefile`s and `ndp.mk` but they didn't seem to have any effect on `make make.library.ndp`, and neither did adding `{-# OPTIONS_GHC -dcore-lint #-}` to the offending file. I also haven't really figured out what the exact GHC invocation is to build the file by hand. On a whim, I tried to just do a clean build (`make remake.library.ndp`) and then the compilation actually got past the file where it got stuck before! It then gave the same "error in desugarer lookup"-panic on a different file, I added `{-# OPTIONS_GHC -dcore-lint #-}` to that file and did a new remake, and it got further again. In this way I've been able to finally build NDP. :) But the process seems to be non-deterministic! Doing a remake sometimes succeeds and sometimes doesn't, and if it doesn't then the offending file isn't even always the same. Sometimes it's one of the files where I added `{-# OPTIONS_GHC -dcore-lint #-}`, but even then I'm still not getting any extra output such as rl provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 11 07:57:45 2008 From: trac at galois.com (GHC) Date: Wed Jun 11 07:50:00 2008 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost> References: <047.a1f2675dc59d934ab527e6234630f65b@localhost> Message-ID: <056.12da28da722acbf833bbd518c22060f0@localhost> #1880: Unify flag descriptions to generate both docs and code ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): This ticket is the only surviving replacement of #1226, so it must be on topic. And the point was that something had gone missing unresolved from that ticket, including the motivation for the changes that seems to elude you (such as easy programatic access to the docs matching a particular version of ghc). But I'm not unwilling to help: if the patch for #1226 had been accepted, every GHC installation would come with a `flagref.txt` file extracted from `flags.xml` serving as the basis for `--full-flag-help`, but also easily useable to extract just the flag names. Meanwhile, you don't have to wait for the grand unification in this ticket to succeed, you could use a subset of the xsl file used in that patch to extract the flag names from `flags.xml` (at least to a first approximation, there are a handful of special cases that may need further tweaking, like `-monly-[432]-regs`): {{{ }}} and then you can run this (after merging back into a single line or script) {{{ $ sed 's/\(]*>\)/ \0\n \]>/' ghc/docs/users_guide/flags.xml | xsltproc flaglist.xsl - }}} to get {{{ -? -help -n -v -vn -V --supported-languages --info --version --numeric-version --print-libdir -ferror-spans -Hsize -Rghc-timing .. }}} btw 1: it would be useful to make sure that `