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/