RE: bug report

[Simon Peyton-Jones]

Hi Alex

Yes I remember talking to you.  It'd be interesting to see your web
crawler when you are done.

Meanwhile, you've definitely hit a bug.  Can you make a reproducible
test case so we can look into it?

Simon

| -Original Message-
| From: Alessandro Warth [mailto:[EMAIL 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 program:
| 
| a.out: internal error: scavenge_stack: weird activation record found
on stack: 6
| Please report this as a bug to glasgow-haskell-bugs@haskell.org,
| or http://www.sourceforge.net/projects/ghc/
| 
| I'm not sure whether or not it makes a difference, but I got the error
| message above directly after the following error message:
| 
| a.out: getHostByName: does not exist (no such host entry)
| 
| I've been able to determine that this is not a sporadic error. In
| fact, this happens every time I get a "getHostByName: does not exist
| (no such host entry)" error message. I can make this happen whenever I
| want.
| 
| Please let me know if there's any other information you would like me
| to send you. Maybe the source code would be helpful?
| 
| Thanks,
| Alex Warth
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #645: Make tick interval configurable

[GHC]

#645: Make tick interval configurable
---+
Reporter:  simonmar|Owner: 
Type:  task|   Status:  new
Priority:  normal  |Milestone:  6.6
   Component:  Runtime System  |  Version:  6.4.1  
Severity:  normal  | Keywords: 
  Os:  Unknown |   Difficulty:  Easy (1 hr)
Architecture:  Unknown |  
---+
The hardwired tick interval of 0.02 seconds is too long.  We should make
 this shorter, and preferably configurable at runtime by an RTS option.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #644: Non-exhaustive patterns in function zip_ty_env

[GHC]

#644: Non-exhaustive patterns in function zip_ty_env
--+-
  Reporter:  simonmar |  Owner: 
  Type:  bug  | Status:  closed 
  Priority:  normal   |  Milestone:  6.4.2  
 Component:  Compiler (Type checker)  |Version:  6.4.1  
  Severity:  normal   | Resolution:  fixed  
  Keywords:   | Os:  Unknown
Difficulty:  Unknown  |   Architecture:  Unknown
--+-
Changes (by simonpj):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Fixed, thank you.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re[2]: bug report

[Bulat Ziganshin]

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 function gethostbyname(), which returns data in a
single static area.


SPJ> Meanwhile, you've definitely hit a bug.  Can you make a reproducible
SPJ> test case so we can look into it?

SPJ> | a.out: internal error: scavenge_stack: weird activation record found
SPJ> on stack: 6
SPJ> | Please report this as a bug to glasgow-haskell-bugs@haskell.org,
SPJ> | or http://www.sourceforge.net/projects/ghc/
SPJ> | 
SPJ> | I'm not sure whether or not it makes a difference, but I got the error
SPJ> | message above directly after the following error message:
SPJ> | 
SPJ> | a.out: getHostByName: does not exist (no such host entry)
SPJ> | 
SPJ> | I've been able to determine that this is not a sporadic error. In
SPJ> | fact, this happens every time I get a "getHostByName: does not exist
SPJ> | (no such host entry)" error message. I can make this happen whenever I
SPJ> | want.
SPJ> | 


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #631: deriving show fails in ghci/ppc

[GHC]

#631: deriving show fails in ghci/ppc
--+-
  Reporter:  [EMAIL PROTECTED]  |  Owner: 
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone: 
 Component:  GHCi |Version:  6.4.1  
  Severity:  major| Resolution: 
  Keywords:   | Os:  Linux  
Difficulty:  Unknown  |   Architecture:  powerpc
--+-
Comment (by simonmar):

 Who is actually responsible for the Debian packaging of GHC on
 powerpc/Linux?  Any takers?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #590: hsc2hs: quoting of macro arguments containing commas

[GHC]

#590: hsc2hs: quoting of macro arguments containing commas
+---
  Reporter:  Dimitry Golubovsky <[EMAIL PROTECTED]>  |  Owner: 
  Type:  bug| Status:  new  
  
  Priority:  low|  Milestone:   
  
 Component:  hsc2hs |Version:  
6.4.1  
  Severity:  minor  | Resolution:   
  
  Keywords: | Os:  
Unknown
Difficulty:  Unknown|   Architecture:  
Unknown
+---
Changes (by simonmar):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * priority:  normal => low
  * os:  => Unknown

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #490: object code blow up by minor source code change

[GHC]

#490: object code blow up by minor source code change
---+
  Reporter:  c_maeder  |  Owner:  simonpj
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone: 
 Component:  Compiler  |Version:  6.4.1  
  Severity:  normal| Resolution:  None   
  Keywords:| Os:  Unknown
Difficulty:  Unknown   |   Architecture:  Unknown
---+
Changes (by simonmar):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * status:  assigned => new
  * owner:  nobody => simonpj
  * os:  => Unknown

Old description:

> {{{
> If you unpack the archive and compile the files with
> optimization by:
>
>  time ghc -no-recomp --make -O HasCASL/hacapa.hs
>
> This takes about 5 minutes and generates an unstripped
> binary of 4MB.
>
> Apply the (little) patch for HugesPJ.hs -- the one I've
> sent before and that is included as "patch" in the
> top-level directory. Our (slightly modified) copy of
> HughesPJ.hs is Common/Lib/Pretty.hs:
>
>  patch -p0 Common/Lib/Pretty.hs patch
>
> Now compilation takes 7 minutes and the binary gets
> size 6 MB. Particularly the file HasCASL/PrintLe.o has
> grown from 90 KB to 2 MB. (Compiling HasCASL/PrintLe.hs
> takes visibly longer, too)
>
> (Patching can be reversed by:
>  patch -p0 -R Common/Lib/Pretty.hs patch
> )
>
> This blow-up of object code caused a link failure on
> our mac for a final (stripped) binary that should have
> a size of around 36 MB.
>
> (The link failure on macs is another issue that may
> need attention in the future.)
>
> The data below is obtained with ghc-6.4.1 under linux.
>
> Cheers Christian
>
> [EMAIL PROTECTED]:~/haskell/examples> uname -a
> Linux turing 2.6.11.4-21.9-default #1 Fri Aug 19
> 11:58:59 UTC 2005 i686 i686 i386 GNU/Linux
> [EMAIL PROTECTED]:~/haskell/examples> ghc --version
> The Glorious Glasgow Haskell Compilation System,
> version 6.4.1
> [EMAIL PROTECTED]:~/haskell/examples> gcc --version
> gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
> Copyright (C) 2003 Free Software Foundation, Inc.
> [...]
> [EMAIL PROTECTED]:~/haskell/examples> time ghc -no-recomp
> --make -O HasCASL/hacapa.hs
> Chasing modules from: HasCASL/hacapa.hs
> Compiling Common.Lib.State ( ./Common/Lib/State.hs,
> ./Common/Lib/State.o )
> [...]
> Compiling Main ( HasCASL/hacapa.hs,
> HasCASL/hacapa.o )
> Linking ...
>
> real6m0.739s
> user5m42.199s
> sys 0m9.590s
> [EMAIL PROTECTED]:~/haskell/examples> ll a.out
> HasCASL/PrintLe.o
> -rwxr-xr-x  1 maeder wimi 4674747 2005-12-01 14:17 a.out
> -rw-r--r--  1 maeder wimi   90308 2005-12-01 14:14
> HasCASL/PrintLe.o
> [EMAIL PROTECTED]:~/haskell/examples> patch -p0
> Common/Lib/Pretty.hs patch
> patching file Common/Lib/Pretty.hs
> Hunk #1 succeeded at 564 (offset -42 lines).
> Hunk #2 succeeded at 609 (offset -42 lines).
> [EMAIL PROTECTED]:~/haskell/examples> time ghc -no-recomp
> --make -O HasCASL/hacapa.hs
> Chasing modules from: HasCASL/hacapa.hs
> Compiling Common.Lib.State ( ./Common/Lib/State.hs,
> ./Common/Lib/State.o )
> [...]
> Compiling Main ( HasCASL/hacapa.hs,
> HasCASL/hacapa.o )
> Linking ...
>
> real8m7.962s
> user7m46.492s
> sys 0m12.345s
> [EMAIL PROTECTED]:~/haskell/examples> ll a.out
> HasCASL/PrintLe.o
> -rwxr-xr-x  1 maeder wimi 6470827 2005-12-01 14:42 a.out
> -rw-r--r--  1 maeder wimi 2007272 2005-12-01 14:40
> HasCASL/PrintLe.o
>
> }}}

New description:

 {{{
 If you unpack the archive and compile the files with
 optimization by:

  time ghc -no-recomp --make -O HasCASL/hacapa.hs

 This takes about 5 minutes and generates an unstripped
 binary of 4MB.

 Apply the (little) patch for HugesPJ.hs -- the one I've
 sent before and that is included as "patch" in the
 top-level directory. Our (slightly modified) copy of
 HughesPJ.hs is Common/Lib/Pretty.hs:

  patch -p0 Common/Lib/Pretty.hs patch

 Now compilation takes 7 minutes and the binary gets
 size 6 MB. Particularly the file HasCASL/PrintLe.o has
 grown from 90 KB to 2 MB. (Compiling HasCASL/PrintLe.hs
 takes visibly longer, too)

 (Patching can be reversed by:
  patch -p0 -R Common/Lib/Pretty.hs patch
 )

 This blow-up of object code caused a link failure on
 our mac for a final (stripped) binary that should have
 a size of around 36 MB.

 (The link failure on macs is another issue that may
 need attention in the future.)

 The data below is obtained with ghc-6.4.1 under linux.

 Cheers Christian

 [EMAIL PROTECTED]:~/haskell/examples> uname -a
 Linux turing 2.6.11.4-21.9-default #1 Fri Aug 19
 11:58:59 UTC 2005 i686 i686 i386 GNU/Linux
 [EMAIL PROTECTED]:~/haskell/examples> ghc --version
 The Glorious Glasgow Haskell Compilation System,
 version 6.4.1
 [EMAIL PROTECTED]:~/haskell/examples> gcc --version
 gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
 Copyright (C) 2003 Free Softwa

Re: [GHC] #462: Incomplete pattern warnings with GADTs

[GHC]

#462: Incomplete pattern warnings with GADTs
---+
  Reporter:  bring |  Owner:  nobody  
  Type:  bug   | Status:  assigned
  Priority:  low   |  Milestone:  
 Component:  Compiler  |Version:  6.4.1   
  Severity:  minor | Resolution:  None
  Keywords:| Os:  Unknown 
Difficulty:  Unknown   |   Architecture:  Unknown 
---+
Changes (by simonpj):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * severity:  normal => minor
  * priority:  normal => low
  * os:  => Unknown

Comment:

 Adding proper pattern-match overlap warnings that take account of GADTs is
 indeed a good project.  But not one we plan to tackle very soon.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #457: Strictness problem

[GHC]

#457: Strictness problem
-+--
  Reporter:  nilsanders  |  Owner:  simonpj
  Type:  bug | Status:  new
  Priority:  normal  |  Milestone: 
 Component:  Compiler|Version:  6.4.1  
  Severity:  minor   | Resolution:  None   
  Keywords:  | Os:  Unknown
Difficulty:  Unknown |   Architecture:  Unknown
-+--
Changes (by simonpj):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * status:  assigned => new
  * owner:  nobody => simonpj
  * os:  => Unknown

Comment:

 Related to #317.

 Caused by the fact that we eta-expand around the case expression.  Not
 eta-expanding hurts performance in important cases (we think).  Still
 thinking what to do about this; it's technically wrong but seldom seems to
 bite in practice.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #455: mkProtoBCO: stack use won't fit in 16 bits 79141

[GHC]

#455: mkProtoBCO: stack use won't fit in 16 bits 79141
---+
  Reporter:  simonmar  |  Owner:  simonmar
  Type:  bug   | Status:  assigned
  Priority:  normal|  Milestone:  
 Component:  Compiler  |Version:  6.4 
  Severity:  normal| Resolution:  None
  Keywords:| Os:  Unknown 
Difficulty:  Unknown   |   Architecture:  Unknown 
---+
Changes (by simonmar):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * status:  new => assigned
  * os:  => Unknown

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #451: GHC poor type-checker error message

[GHC]

#451: GHC poor type-checker error message
--+-
  Reporter:  isaacdupree  |  Owner:  simonpj
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone: 
 Component:  Compiler (Type checker)  |Version:  6.4
  Severity:  normal   | Resolution:  None   
  Keywords:   | Os:  Unknown
Difficulty:  Unknown  |   Architecture:  Unknown
--+-
Changes (by simonpj):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * status:  assigned => new
  * owner:  nobody => simonpj
  * os:  => Unknown

Old description:

> {{{
> Here is a very tricky GHC (6.4) error message I found.
>  I have simplified the context from where I found it,
> but the error is basically the same (still rather less
> confusing than the real thing, where Value ::
> [TString], TString :: [(String,Textdomain)], and error
> messages talked about, e.g., [[([Char],Textdomain)]]
> instead of [[Char]]). I had to run the original through
> Hugs to find my mistake there. Here is the code:
>
> > import Data.List(intersperse)
> > type Value = String
> > -- unifyEnd :: [key] -> [Value] -> [Value]
> > -- this example assumes (length ks <= length vs)
> > unifyEnd ks vs =
> >   let (fvs,evs) = splitAt (length ks - 1) vs
> >   in fvs ++ concat (intersperse "," evs)
>
> Here is the GHC-6.4 error message:
> BadErrorMessage.lhs:10:41:
> Couldn't match `[Char]' against `Char'
>   Expected type: [[Char]]
>   Inferred type: [Char]
> In the second argument of `intersperse', namely `evs'
> In the first argument of `concat', namely
> `(intersperse "," evs)'
>
> The error message when the type signature is
> uncommented at least might lead to less pursuing of the
> wrong things, claiming the literal `","' is in error
> instead, but does not get to the location of the error.
>
> The Hugs error, while not perfect, has got the location
> correct: it shows me the part I erred in:
> ERROR "BadErrorMessage.lhs":8 - Type error in application
> *** Expression : fvs ++ concat (intersperse "," evs)
> *** Term   : fvs
> *** Type   : [[Char]]
> *** Does not match : [Char]
>
> I had forgotten to put [ ] around concat (...), i.e.
> fvs ++ [concat (intersperse "," evs)]
> is the corrected fragment of the definition.
>
> GHC did not appear to realize that the two arguments to
> 'intersperse' were currently consistent with each
> other, given intersperse's type signature of a -> [a]
> -> [a], but would not be if the type of the one claimed
> to be in error were changed to the "expected" type. (If
> it could say that they were both the wrong type, that
> would be another choice it had that makes sense, but
> that would be two human errors, perhaps less likely
> than one.)
>
> }}}

New description:

 {{{
 Here is a very tricky GHC (6.4) error message I found.
  I have simplified the context from where I found it,
 but the error is basically the same (still rather less
 confusing than the real thing, where Value ::
 [TString], TString :: [(String,Textdomain)], and error
 messages talked about, e.g., [[([Char],Textdomain)]]
 instead of [[Char]]). I had to run the original through
 Hugs to find my mistake there. Here is the code:

 > import Data.List(intersperse)
 > type Value = String
 > -- unifyEnd :: [key] -> [Value] -> [Value]
 > -- this example assumes (length ks <= length vs)
 > unifyEnd ks vs =
 >   let (fvs,evs) = splitAt (length ks - 1) vs
 >   in fvs ++ concat (intersperse "," evs)

 Here is the GHC-6.4 error message:
 BadErrorMessage.lhs:10:41:
 Couldn't match `[Char]' against `Char'
   Expected type: [[Char]]
   Inferred type: [Char]
 In the second argument of `intersperse', namely `evs'
 In the first argument of `concat', namely
 `(intersperse "," evs)'

 The error message when the type signature is
 uncommented at least might lead to less pursuing of the
 wrong things, claiming the literal `","' is in error
 instead, but does not get to the location of the error.

 The Hugs error, while not perfect, has got the location
 correct: it shows me the part I erred in:
 ERROR "BadErrorMessage.lhs":8 - Type error in application
 *** Expression : fvs ++ concat (intersperse "," evs)
 *** Term   : fvs
 *** Type   : [[Char]]
 *** Does not match : [Char]

 I had forgotten to put [ ] around concat (...), i.e.
 fvs ++ [concat (intersperse "," evs)]
 is the corrected fragment of the definition.

 GHC did not appear to realize that the two arguments to
 'intersperse' were currently consistent with each
 other, given intersperse's type signature of a -> [a]
 -> [a], but would not be if the type of the one claimed
 to be in error were changed to the "expected" type. (If
 it

Re: [GHC] #342: GHC: panic! (compiler bug?)

[GHC]

#342: GHC: panic! (compiler bug?)
---+
  Reporter:  nobody|  Owner:  nobody
  Type:  bug   | Status:  closed
  Priority:  normal|  Milestone:
 Component:  Compiler  |Version:  6.4.1 
  Severity:  major | Resolution:  worksforme
  Keywords:| Os:  Unknown   
Difficulty:  Unknown   |   Architecture:  Unknown   
---+
Changes (by simonmar):

  * architecture:  => Unknown
  * resolution:  None => worksforme
  * difficulty:  => Unknown
  * status:  assigned => closed
  * os:  => Unknown

Comment:

 We haven't managed to find a reproducible test case for this one, so
 closing it for now.  Will re-open if it reappears.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Guest login now requred to create bugs

[Simon Marlow]

Following recent spam (thankfully only one instance), I've made it so
that you have to log in (username guest, password guest) in order to
create and edit bugs on the bug tracker.  Sorry for the inconvenience.

Cheers,
Simon

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Signal inconsistency between GHC and GHCi

[Simon Marlow]

Sven Panne wrote:

Am Sonntag, 1. Januar 2006 19:40 schrieb Bulat Ziganshin:


Sunday, January 01, 2006, 2:27:01 PM, you wrote:


[ usleep/nanosleep trouble deleted... ]


may be you comile with -threaded? ghci don't use this option, afaik


SP> The SIGALRM happen with purely interpreted code and even without
loading any SP> code at all into GHCi... :-(

i say that your COMPILED code works ok because it uses -threaded, but
GHCi fails because it just never use this option



Well, you can safely assume that I would have mentioned any strange 
commandline flags used for compilation, so don't jump to wild assumptions... 
It was plain old "ghc --make Blah.hs" on x86 SuSE Linux. And no, GHCi did not 
get any options, either.


Anyway, the question was (slightly reformulated): Why does GHCi seize the 
SIGALRM resource and why does it receive high-frequency signals even when 
idling on the prompt? Neither is this very power-saving-friendly nor 
necessary and can lead to problems with external libraries. Perhaps our RTS 
Grand Master SimonM can comment on this. :-)


Looking at the code in ghc/rts/posix/Itimer.c (ghc/rts/Itimer.c in STABLE):

#ifdef RTS_SUPPORTS_THREADS
#define ITIMER_FLAVOUR  ITIMER_REAL
#define ITIMER_SIGNAL   SIGALRM
#else
#define ITIMER_FLAVOUR  ITIMER_VIRTUAL
#define ITIMER_SIGNAL   SIGVTALRM
#endif

So the -threaded RTS uses ITIMER_REAL for obscure reasons detailed in
the comment next to that code.

I don't understand why you're seeing a difference with GHCi, unless your
GHCi was somehow compiled with -threaded? (that isn't the default).

If there's a better way to get a timer signal that is transparent to the
running code, I'm all ears.

Cheers,
Simon

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #447: segmentation fault when profiling large case

[GHC]

#447: segmentation fault when profiling large case
+---
  Reporter:  nobody |  Owner:  simonmar
  Type:  bug| Status:  new 
  Priority:  normal |  Milestone:  6.4.2   
 Component:  Profiling  |Version:  6.4 
  Severity:  normal | Resolution:  None
  Keywords: | Os:  Unknown 
Difficulty:  Unknown|   Architecture:  Unknown 
+---
Changes (by Alex Iliev):

  * architecture:  => Unknown
  * difficulty:  => Unknown
  * os:  => Unknown

Comment:

 I had the same segfault problem, on other code, also with large case
 statements (but lots of other things too). It went away after upgrading
 from 6.4 to 6.4.1 in debian unstable.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #646: ASSERT fails on newtype + forall

[GHC]

#646: ASSERT fails on newtype + forall
+---
Reporter:  guest|Owner: 
Type:  bug  |   Status:  new
Priority:  normal   |Milestone:  6.6
   Component:  Compiler (Type checker)  |  Version: 
Severity:  normal   | Keywords: 
  Os:  MacOS X  |   Difficulty:  Unknown
Architecture:  powerpc  |  
+---
The following module causes an ASSERT failure in the HEAD version of ghc
 6.5.

 {{{
  BadNewtype.hs 
 module BadNewtype where

 newtype Foo = forall a . Foo a

 

 > ghci-6.5 -fglasgow-exts BadAssert.hs

 Loading package base-1.0 ... linking ... done.
 [1 of 1] Compiling BadAssert( BadAssert.hs, interpreted )
 *** Exception: ASSERT failed! file typecheck/TcTyClsDecls.lhs, line 466
 >

 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs