RE: GHC Bug report

eaval of the way inlining works. Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Jason Dagit Sent: 02 October 2009 00:01 To: glasgow-haskell-bugs@haskell.org Cc: Simon Marlow; Ian Lynagh Subject: Fwd: GHC Bug report [I just f

Fwd: GHC Bug report

[I just found out that there is a dedicated bugs email address so forwarding the original message there.] Hello, I've created a small example of the program I have at this URL with the output of -ddump-simpl: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10109#a10109 Notice that on line 139, I

Re: [GHC] #3313: Uncertain bug report (panic!)

#3313: Uncertain bug report (panic!) --+- Reporter: semanticprecision |Owner: Type: bug| Status: closed Priority: normal |Milestone

Re: [GHC] #3313: Uncertain bug report (panic!)

#3313: Uncertain bug report (panic!) --+- Reporter: semanticprecision |Owner: Type: bug| Status: new Priority: normal |Milestone

Re: [GHC] #3313: Uncertain bug report (panic!)

#3313: Uncertain bug report (panic!) ---+ Reporter: semanticprecision | Owner: Type: bug| Status: new Priority: normal | Milestone: Component

Re: [GHC] #3313: Uncertain bug report (panic!)

#3313: Uncertain bug report (panic!) ---+ Reporter: semanticprecision | Owner: Type: bug| Status: new Priority: normal | Milestone: Component

[GHC] #3313: Uncertain bug report (panic!)

#3313: Uncertain bug report (panic!) --+- Reporter: semanticprecision | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version

Re: bug report: picoseconds handling in System.Time

Andrei Paskevich wrote: The diffClockTimes function can generate TimeDiff's with a negative value of tdPicosec. When you pass such a TimeDiff to addToClockTime, the latter may send negative picoseconds to toClockTime, provoking the error "picoseconds out of range". While we are at it, please,

bug report: picoseconds handling in System.Time

The diffClockTimes function can generate TimeDiff's with a negative value of tdPicosec. When you pass such a TimeDiff to addToClockTime, the latter may send negative picoseconds to toClockTime, provoking the error "picoseconds out of range". While we are at it, please, teach normalizeTimeDiff t

Bug Report: Visual Haskell, 0.2 build hangs on 0.0 projects

Hello All, I don't know if anyone else has experienced this. I have a couple of projects that I have been working on using version 0.0, and after upgrading an trying to perform a build or rebuild, it seems like it starts the build process but nothing gets displayed in the output window and vs stop

Re: bug report

Steve Dekorte wrote: On 10 May 2006, at 02:17 am, Duncan Coutts wrote: On Tue, 2006-05-02 at 08:56 -0700, Steve Dekorte wrote: % darcs annotate slice darcs: internal error: evacuate: strange closure type 14402 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http

[issue168] bug report

David Roundy <[EMAIL PROTECTED]> added the comment: I'm setting this as a "not our bug", since it looks like it can only be a ghc bug to me. David -- priority: -> not-our-bug status: unread -> chatting Darcs issue tracker <[EMAIL PROTECTED]>

Re: bug report

Steve, If this compiler were ghc 6.4.2, this is probably bug 751, which has been reported by by others using ghc 6.4.2 from darwinports while building darcs. I am building a compiler with debugging turned on; perhaps that will give some clues about the apparent RTS crash that we've been seeing.

Re: bug report

On 10 May 2006, at 02:17 am, Duncan Coutts wrote: On Tue, 2006-05-02 at 08:56 -0700, Steve Dekorte wrote: % darcs annotate slice darcs: internal error: evacuate: strange closure type 14402 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/p

Re: bug report

On Tue, 2006-05-02 at 08:56 -0700, Steve Dekorte wrote: > % darcs annotate slice > darcs: internal error: evacuate: strange closure type 14402 > Please report this as a bug to glasgow-haskell-bugs@haskell.org, > or http://www.sourceforge.net/projects/ghc/ Would you mind answering a few m

bug report

% darcs annotate slice darcs: internal error: evacuate: strange closure type 14402 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell

Re[2]: bug report

Hello Simon, Wednesday, January 04, 2006, 11:22:50 AM, you wrote: Simon, look at [EMAIL PROTECTED] part of this SimonM's letter: If anyone is interested, this turned out to be a bug in the Network.BSD module, namely that getHostByName isn't thread safe because it is based on the C library funct

RE: bug report

PROTECTED] | Sent: 29 December 2005 20:26 | To: glasgow-haskell-bugs@haskell.org | Cc: Simon Peyton-Jones | Subject: bug report | | Hello, | | My name is Alex Warth. I've been working on a multi-threaded web | crawler that uses STM, and I just got a strange error message while | running my prog

RE: bug report, stg_ap_v_ret

On Fri, 2005-10-28 at 09:54 +0100, Simon Marlow wrote: > Similar errors have been reported before... basically we need a > reproducible test case in order to track it down. If it happens > reliably for you with that repository (or even semi-reliably), then can > you just tar up the darcs repo and

RE: bug report, stg_ap_v_ret

On 27 October 2005 21:40, Tim Daly Jr. wrote: > [EMAIL PROTECTED]:~$ darcs get /e/phpoo > Copying patch 1066 of 2079...darcs.exe: internal error: stg_ap_v_ret > Please report this as a bug to glasgow-haskell-bugs@haskell.org, > or http://www.sourceforge.net/projects/ghc/ > [EMAIL PROTECTED

bug report, stg_ap_v_ret

Hi guys, just saw this: [EMAIL PROTECTED]:~$ darcs get /e/phpoo Copying patch 1066 of 2079...darcs.exe: internal error: stg_ap_v_ret Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ [EMAIL PROTECTED]:~$ darcs --version 1.0.3 (rel

RE: Bug Report: stg_ap_p_ret

I think you forgot to attach the code! BTW, we need the source to the whole program, and instructions for reproducing the problem. If the program uses pseudo randomness, then have it output the seed at the beginning of the run so that we can run it again with the same seed. Cheers, Simon

Bug Report: stg_ap_p_ret

Good day. I'm using GHC 6.2.1, and have had much success with it. However, yesterday I got a strange error I've never before seen. Mosaic: internal error: stg_ap_p_ret Please report this as a bug to glasgow-haskell- [EMAIL PROTECTED], or http://www.sourceforge.net/projects/g

RE: Bug report.

On 25 March 2004 09:06, MR K P SCHUPKE wrote: > Started getting: > > ghc-6.2.1.20040313: panic! (the `impossible' happened, GHC version > 6.2.1.20040313): mkTyVar a1 {- tv a75q -} > > Please report it as a compiler bug to > [EMAIL PROTECTED], > or http://sourceforge.net/projects/ghc/. >

Bug report.

Started getting: ghc-6.2.1.20040313: panic! (the `impossible' happened, GHC version 6.2.1.20040313): mkTyVar a1 {- tv a75q -} Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. today... definitely a but to do with class inference, as it star

bug report

I just try this Prelude> let f 0 = 1 ghc-6.0: panic! (the `impossible' happened, GHC version 6.0): getLinkDeps No iface for []GHCziErr Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Pierre Valarcher LIFAR

ghci bug report does not start up !!

SunOS 5.8 Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) Bootstraped from 4.08.2 then compiled the CVS. $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.05.20030323, for Has

sloppy bug report

Hi, Apologies for the sloppiness of this bug report. in ghc 5.04.2 I get this message: ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2): coreSyn/Subst.lhs:385: Non-exhaustive patterns in function zip_ty_env I would love to try and give you a simple test case,

RE: bug report

> I am reporting a bug in the GHCi Haskell interpreter as requested by > the program itself. GHC is 5.04.2 running on SunOS 5.8. > > The interpreter encountered a panic condition when trying to load a > parser produced by Happy the parser generator. Yes, this is a known bug in 5.04.2 (although I

bug report

Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: [EM

RE: uh oh, another bug report :) (it and big computations)

> *Foo> it > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule it Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

uh oh, another bug report :) (it and big computations)

Me again :) Here's the offending code: > module Foo where > foo :: Int -> [((Int,Int), Int)] > foo width = [((i,j),if i==j then 0 else 1) | i <- [1..50], j <- > [1..width]] largely arbitrary, the point is to make something that takes a while to compute. now, using ghci (5.04.1, sparc sola

RE: Bug report for ghci: using Word64

icult at best. J | -Original Message- | From: Laura McKinney [mailto:[EMAIL PROTECTED]] | Sent: Monday, January 07, 2002 4:47 PM | To: [EMAIL PROTECTED] | Subject: Bug report for ghci: using Word64 | | | We are using Word64 and encountered the following problem | upon loading into |

Bug report for ghci: using Word64

We are using Word64 and encountered the following problem upon loading into ghci: ghc-5.02.1: panic! (the `impossible' happened, GHC version 5.02.1): ByteCodeGen.mkUnpackCode LW_ Program works under ghc. Laura McKinney ___ Glasgow-haskell-bu

silly bug report

Okay, don't lose any sleep over it, but eris% ghc -Wall -O3 -o MkHTML MkHTML.hs ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unknown opt level Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. I'm inclin

RE: small bug report for 5.02

> Dear ghc-5.02-linux-i386-unknown, > > Here is quite a simple bug report. > > main = putStr $ shows ((head xs)+(last xs)) "\n" > where xs = [1..99000] > ghc -c Main.hs > ghc -o run Main.o > ./run +RTS

small bug report for 5.02

Dear ghc-5.02-linux-i386-unknown, Here is quite a simple bug report. main = putStr $ shows ((head xs)+(last xs)) "\n" where xs = [1..99000] ghc -c Main.hs ghc -o run Main.o ./run +RTS -M100k -RTS 99001 ./run +RTS -M300k -

RE: compiler bug report

mon Marlow | Cc: [EMAIL PROTECTED] | Subject: Re: compiler bug report | | | I can't reliably repro the bug, but it happens to me a *lot*. | At least one every hour or two...not only on that file...I | don't think it happens if I delete all the .o files...not | sure though... | | - H

Re: compiler bug report

I can't reliably repro the bug, but it happens to me a *lot*. At least one every hour or two...not only on that file...I don't think it happens if I delete all the .o files...not sure though... - Hal Simon Marlow wrote: > > Hi there, > > Thanks for the report. I can't repro the bug though -

RE: compiler bug report

n Marlow [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 01, 2001 9:51 AM > To: Hal Daume; [EMAIL PROTECTED] > Subject: RE: compiler bug report > > > Hi there, > > Thanks for the report. I can't repro the bug though - after > I commented > out the definitio

RE: compiler bug report

Hi there, Thanks for the report. I can't repro the bug though - after I commented out the definition of beginWithBy at the end of Util.hs (it had some type errors), and tried the exact same sequence of commands in ghci, it happily re-loaded Util.o at the end. Is there any more information you c

compiler bug report

Here is a transcript: enescu:/nfs/isd/hdaume/stat-sum-ulf 54% ghci -package lang ghci -package lang ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.00.2, For Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\

RE: DriverMkDepend crashes for bad import paths (bug report + patch)

> This is a cosmetic bug related to path errors. [ snip ] Thanks, I've committed a (slightly modified) version of your patch. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgo

DriverMkDepend crashes for bad import paths (bug report + patch)

This is a cosmetic bug related to path errors. I have a module that imports a non-existing module, and run ghc on it providing a non-existing path. I am using ghc-5.00 checked out yesterday from anoncvs and compiled without any special fine tuning. Compilation works:

RE: Bug report

module. Simon | -Original Message- | From: Axel Krauth [mailto:[EMAIL PROTECTED]] | Sent: 05 October 2000 16:19 | To: [EMAIL PROTECTED] | Subject: Bug report | | | -- Sorry, but if ghc tells me to report it.. | -- | -- Using :The Glorious Glasgow Haskell Compilation System, | version 4.08.1 |

Bug report

-- Sorry, but if ghc tells me to report it.. -- -- Using :The Glorious Glasgow Haskell Compilation System, version 4.08.1 -- (if this is also needed) : gcc 2.95.2 ( also egcs 1.1.2) -- ghc -v -fglasgow-exts -i/usr/local/lib/ghc-4.08.1/imports/lang/ \ -- -o bug bug.hs -lHSlang -- -- message by gh

Bug report: mkPrimReturnCode: Upd tpl4{-c9vM-}

Hello there, Just after I added some strictness annotations (!) to an algebraic datatype, ghc-4.08 paniced and halted with the following error message: panic! (the `impossible' happened): mkPrimReturnCode: Upd tpl4{-c9vM-} Please report it as a compiler bug to [EMAIL PROTECTED] The

RE: bug report

> Compiling the following with ghc-4.06 produces an erroneous > error message: > > module O where > > a :: Int > a = 1 > > b :: Int > b = 2 > > c :: Int > c = 3 > > f :: Int -> Bool > f i = case i of >a -> True >b -> True >c -> True > > > The compiler complains: > > o.hs:14: P

bug report

Hi Volker, It is legal Haskell, but it isn't doing what you think. The patterns in a case statement introduce *new* variables, their scope is the right hand side expression of their alternative. Since the a,b,c patterns are just variables they will match anything, and the first alternative w

bug report

Hello. Compiling the following with ghc-4.06 produces an erroneous error message: module O where a :: Int a = 1 b :: Int b = 2 c :: Int c = 3 f :: Int -> Bool f i = case i of a -> True b -> True c -> True The compiler complains: o.hs:14: Pattern match(es) are overlapped in a grou

RE: Bug Report: Export List in Module

> I just found out that module definitions of the > following kind > > > module Commas( , , ) where > > > are accepted by ghc. One comma also seems to be fine. Yes, GHC's parser is a little more liberal about extra punctuation than it should be. I don't particularly want to fix this, but if

Bug Report: Export List in Module

Hello, I just found out that module definitions of the following kind > module Commas( , , ) where are accepted by ghc. One comma also seems to be fine. Regards, Marc van Dongen

The Daily Bug Report for Feb. 22nd

GHC-4.02 and yesterday's GHC-4.03 don't like the following (rather senseless) module: -- Foo.hs - module Foo where import IOExts(unsafePerformIO) bar :: [Int] -> IO (Bool,[Int]) bar tns = do baz_ <- barAux 8 let baz = baz_ == false res <- if baz

H/Direct-0.14 bug report: confusion with interfaces

Hello. H/Direct-0.14 doesn't generate a correct haskell module from the following IDL-File: module Probe { interface Typ {}; Typ erz_typ([in] int a); int abfr_typ([in] Typ t); void zer_typ([in] Typ t); }; The generated

RE: bug report

essage- > From: Marc van Dongen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 17, 1998 12:21 PM > To: [EMAIL PROTECTED] > Subject: bug report > > > Hi there, > > > I can't see why the following will not compile with 3.02 > > > > module M

RE: bug report 4.00

> While compiling some stuff with 4.00 I get the following > output before compilation stops. > > [snip] > > GNU CPP version 2.7.2 (sparc) > #include "..." search starts here: > #include <...> search starts here: > . > /usr/local/ghc-4.00/lib/ghc-4.00/includes > /usr/local/ghc-4.00/lib/ghc-4.

bug report 4.00

Hi there, While compiling some stuff with 4.00 I get the following output before compilation stops. [snip] GNU CPP version 2.7.2 (sparc) #include "..." search starts here: #include <...> search starts here: . /usr/local/ghc-4.00/lib/ghc-4.00/includes /usr/local/ghc-4.00/lib/ghc-4.00/include

bug report

Hi there, I can't see why the following will not compile with 3.02 > module Main( main ) where > data A a = A (a,a) > instance (Show a,Ord a) => Num (a,a) where > (+) a a' = a > instance (Show a,Ord a) => Eq (A a) where > (==) a a' = True > instance Show (A String) where > showsPrec

small correction to bug report

In addition to my report on ghc-4 panic of October 20 1998: after making ghc-4 compile Pfact_.hs we also have to improve in Makefile ..$(r)/RsePol_ to ..$(r)RsePol_ just to make the project make :-) -- Sergey Mechveliani [EMAIL PROTECTED]

Re: ``bug report''

Marc van Dongen wrote: > [ program omitted ] > However, for ``f'' the following is reported. > > tmp.lhs:4: > Pattern match(es) are overlapped in the definition of function `f' > "=" = ... > > There are no complaints for definition for ``g''. This is a traditional "bug" GHC, see

``bug report''

Hi there, In ghc-3.02 the following program compiles fine. > module Main( main ) where > f :: String -> Int > f "=<" = 0 > f "=" = 0 > g :: [Char] -> Int > g ['=','<'] = 0 > g ['='] = 0 > main = return () However, for ``f'' the following is reported. tmp.lhs:4: Pattern match(es) a

Re: bug report 3.00

> > panic! (the `impossible' happened): > > fun_result_ty: 6 GHC.Int#{-3e-} > > -> GHC.Int#{-3e-} > > -> b_trKC > > -> PolyParse.HappyState{-rq9-} b_trKC c_trKD > > -> [PolyParse.HappyState{-rq9-} b_trKC c_trKD] > >

Re: bug report 3.00

Marc van Dongen= writes: > > While compiling some happy output with 3.00 I came > across the following: > > > NOTE: Simplifier still going after 4 iterations; bailing out. > > NOTE: Simplifier still going after 4 iterations; bailing out. > > panic! (the `impossible' happened): > fun_

bug report 3.00

While compiling some happy output with 3.00 I came across the following: NOTE: Simplifier still going after 4 iterations; bailing out. NOTE: Simplifier still going after 4 iterations; bailing out. panic! (the `impossible' happened): fun_result_ty: 6 GHC.Int#{-3e-} ->

Re: bug report

Simon L Peyton Jones <[EMAIL PROTECTED]> writes: > > So are types not longer allowed in instance declarations? > > Yes they're allowed, but it's just as if you'd written the > expanded type. Any two instance decls that don't overlap are > allowed. You can write > > instance C (Blah,Int

Re: bug report

Mark says: > > data Blah = Blah > > type Tuple = (Blah,Int) > > > instance Show Tuple where > > showsPrec _ _ _ > > = error [] > > No instance for: `Show Blah' > arising from use of `PrelBase.$mshowList', at tmp.lhs:8 > > I know that instances of classes shouldn't be types,

bug report

The following won't compile under 3.00 > data Blah = Blah > type Tuple = (Blah,Int) > instance Show Tuple where > showsPrec _ _ _ > = error [] No instance for: `Show Blah' arising from use of `PrelBase.$mshowList', at tmp.lhs:8 I know that instances of classes shouldn't be ty

bug report

While compiling some stuff with 3.00 which normally compiles with 2.10, I came across the following: panic! (the `impossible' happened): ERROR: can't generate code for polymorphic case probably a mis-use of `seq' or `par'; the User's Guide

Re: bug report

Marc van Dongen= <[EMAIL PROTECTED]> writes: > One of my programs caused a: > > Entered Forward_Ref 7f0928: Should never occur! We've heard of this one before, but haven't actually been able to reproduce it. Anyway, the upshot is that we're rewriting the profiling support for the new run-time

bug report

Hi there, One of my programs caused a: Entered Forward_Ref 7f0928: Should never occur! ghc 2.09 profiled with -O2. This happened afeter 180 second run-time so it's probably very difficult to isolate the source of the problem. Let me know if more information is needed. A previous run with di

Re: bug report

Marc van Dongen= <[EMAIL PROTECTED]> writes: > While compiling some stuff I came across the following: > compiling with -O did failed without any error message > at all. > compiling with -O2 succeeded > > ? > > Any idea what could have caused it? I can tell you how to > reproduce this if wa

bug report

Dear all, While compiling some stuff I came across the following: compiling with -O did failed without any error message at all. compiling with -O2 succeeded ? Any idea what could have caused it? I can tell you how to reproduce this if wanted. Regards, Marc

Re: bug report

Alex Ferguson <[EMAIL PROTECTED]> writes: > > Did you do 'make install' in ghc, instead of using the binary > > distribution? > > I did make install from a build from source, yes, not least as there was > no binary distrib. available at that point. ;-) Right - it's a bug that the link isn't in

Re: bug report

> Did you do 'make install' in ghc, instead of using the binary > distribution? I did make install from a build from source, yes, not least as there was no binary distrib. available at that point. ;-) > Hard links are a pain for several reasons - if you install a new ghc > over the existing on

Re: bug report

Alex Ferguson <[EMAIL PROTECTED]> writes: > > It does for me - but the sense of the link is reversed (i.e. now ghc > > points to ghc-2.09, which is the real driver). > > Odd. It doesn't seem to do this at all for me. There's no "ghc-2.09", > and "ghc" isn't a link. I can't see where in the ma

Re: bug report

> From [EMAIL PROTECTED] Fri Nov 28 11:48:59 1997 > This is another file missing from the source distribution. The new > one is now up, and it contains all the necessary files. Can you put this up as a patch, too? > It does for me - but the sense of the link is reversed (i.e. now ghc > point

Re: bug report

Marc van Dongen= <[EMAIL PROTECTED]> writes: > When compiling with 2.0899, Gee, I really must fix that... > I get the following error at linking stage: > > Undefined first referenced > symbol in file > getBufferMode

bug report

Hi there, When compiling with 2.0899, I get the following error at linking stage: Undefined first referenced symbol in file getBufferMode /usr/local/ghc-2.09/lib/libHS.a(IOHandle__131.o) Main_main_closure

Re: bug report

> > > module Strange( strange ) where > > > > > strange :: (a,a,a) -> a > > > strange triple > > > | (first triple) == (fst triple) = first triple > > > > > first :: (a,b,c) -> a > > > first (a,b,c) > > > = a > > > > Stange.lhs:5: Couldn't match the type > >`PrelTup.(,,) t

Re: bug report

Thanks, misleading error message this - the pattern guard extension allows you to write qualifiers a la list comprehensions on the left-hand side. The front-end simply re-uses the implementation for list comprehensions to do this, hence the error messages may still be a bit skewed toward list c

bug report

Hi there, ghc-2.0498, complains about list-comprehensions when compiling the following. There's probably some code-transformation going on here. > module Strange( strange ) where > strange :: (a,a,a) -> a > strange triple > | (first triple) == (fst triple) = first triple > first

bug report

Hi there, With ghc-2.04 I can successfully compile the following: > module Buggy( buggy ) where > data L a = L [a] > class (Eq a,Ord a,Num a,Read a,Show a) => Class a where > method :: a -> Bool > instance (Class a) => Class (L a) where > method (L as) = True > instance (Class a) => Eq (L

bug report

I would like to report the following bug in ghc-2.04. Profiling and optimizing with -O2 (I have not and will not try -O) leads to errors like this at link-time: CC_mkZubalancedZ92Z92Z92Zq_struct Blah1.o CC_DICTs_struct Blah2.o CC_mkZubalancedZ92Zq_struct Blah3.o CC_

Re: bug report

Marc, GHC 2.04 correctly says Main.hs:17: Ambiguous overloading arising from use of `g' at Main.hs:23 `PrelBase.Ord' `p{-a17v-}' When checking signature(s) for: `g' | From: Marc van Dongen <[EMAIL PROTECTED]> | Date: Sat, 31 May 1997 14:35:40 +0100 (BST

Re: bug report

Marc van Dongen writes: > Hi, > > While I was constructing an example for ghc-users, I created the following > program which crashed ghc-2.03. > > > module Tmp( g ) where > > > data AB p q = A > > | B p q > > > g :: (Ord p,Ord q) => (AB p q) -> Bool > > g (B _ _) > > = g A > >

bug report

Hi, While I was constructing an example for ghc-users, I created the following program which crashed ghc-2.03. > module Tmp( g ) where > data AB p q = A > | B p q > g :: (Ord p,Ord q) => (AB p q) -> Bool > g (B _ _) > = g A tmp.lhs:6: Warning: Possibly incomplete patter

Re: bug report

Marc you are outstanding at winkling out these bugs. This is an erroneous program because 0 doesn't have type (forall a.a), but it should not crash the compiler. I've fixed it in 2.04. Simon | From: Marc van Dongen <[EMAIL PROTECTED]> | Date: Thu, 29 May 1997 22:38:32 +0100 (BST) | Compiling t

Re: bug report

Good report! The contexts on the signatures in a mutually recursive group must be the same (i.e. unifiable), but GHC wasn't being careful enough.. here they aren't even the same length. Embarassing, but easily fixed. Simon | From: Marc van Dongen <[EMAIL PROTECTED]> | Date: Fri, 30 May 1997 1

bug report

If my memory serves me right, I haven't seen this one in ghc-2.03: *** Pattern-matching error within GHC! This is a compiler bug; please report it to [EMAIL PROTECTED] Fail: "typecheck/Unify.lhs", line 60: incomplete pattern(s) to match in function "unifyTauTyLists" Caused by the followin

bug report

Compiling the code fragment appended at the end of this message, ghc-2.03 fails with the following output: Glasgow Haskell Compiler, version 2.03, for Haskell 1.4 panic! (the `impossible' happened): tcLookupTyVar:a_r6v Please report it as a compiler bug to [EMAIL PROTECTED] H

Re: [bug report] ghc-2.03: exponential number of error messages

| Each additional, no matter how trivial definition causes that the | compiler starts to produces twice as many error messages. In general | adding n definitions gives raise to 7 * 2^n errors, e.g., adding: Yes, I tripped over this too! It could only happen in a compiler written in a functiona

[bug report] ghc-2.03: exponential number of error messages

This is most probably already being addressed as part of the `newtype' bug fixes so I write about it just in case this behavior is unrelated or points to some other deficiency. Previous `newtype' bug inducing code: > newtype Age = MkAge Int deriving (Eq, Show) > instance Num (Age) generates 7 e

[bug report] ghc-2.03: do/let mixtures

Hi, This script: > main = do > putStr "a" > let x = "b" in putStr x > putStr "c" results in: *** Pattern-matching error within GHC! This is a compiler bug; please report it to [EMAIL PROTECTED] Fail: "reader/ReadPrefix.lhs", line 245: pattern-matching failed in case and this: > main

Re: [bug report] ghc-2.03: wrong (!!) fixity; instances for `newtype'

Tomasz, Thanks for the fine bug reports. Keep em coming. | Source of the problem is a declaration in PrelBase.lhs: | infixr 9 !! | According to the Report it should read: | infixl 9 !! Fixed. | 2. The following code | | > newtype Age = MkAge Int deriving (Eq, Show) | > instance Num (Ag

[bug report] ghc-2.03: wrong (!!) fixity; instances for `newtype'

Hello, 1. Compilation of the following code > main = print ([[0]]!!0!!0) fails in ghc-2.03 with the message: bug5.lhs:1: No instance for: PrelBase.Num [PrelBase.Int] bug5.lhs:1: at an overloaded literal: 0 Source of the problem is a declaration in PrelBase.lhs: infixr 9 !! Accord

Re: [bug report] labeled fields in ghc-2.03

Thanks for the bug report. What you say is all too true. It's fixed in my working copy; pending the next release I guess you'll just have to work around it. Sorry. Simon | From: Tomasz Cholewo <[EMAIL PROTECTED]> | Date: Tue, 20 May 1997 05:10:04 GMT | Hi, | | ghc-2.03 ca

[bug report] labeled fields in ghc-2.03

Hi, ghc-2.03 cannot compile the following code, which I think is correct according to the Report: > data X = A {a :: Int} | B {a :: Int} The error message is: Conflicting definitions for: a Defined at bug4.lhs:2 Defined at bug4.lhs:2 In addition the following snippet >

Re: [bug report] ghc-2.03 on mips-sgi-irix6

: discarding polymorphic case:tpl_s4Fl > Warning: discarding polymorphic case:tpl_s4Ft > > panic! (the `impossible' happened): > lookupBindC:no info! > for: d.Eval_aY2 > (probably: data dependencies broken by an optimisation pass) > Hi, thanks for the bug report -

[bug report] ghc-2.03 on mips-sgi-irix6

Hello, Running ghc on the attached (admittedly ugly) file bug2.lhs yields: - Warning: discarding polymorphic case:tpl_s4Ez Warning: discarding polymorphic case:tpl_s4F5 Warning: discarding polymorphic case:tpl_s4Fd Warning: discarding polymorphic case:tpl_s4Fl Warning: discarding polymorphic

Re: Happy bug report

Marc van Dongen writes: > > { > > > happyError :: Int -> [Token] -> a > > happyError i'' _ > > = error errstr > > where errstr = "This code fragment forces Happy to return with" ++ > > "the following error message:\n\n" ++ > > "Fail: Lexical Error: No closin

  1   2   >