[GHC] #1781: Type equality class leads to non-termination

[GHC]

#1781: Type equality class leads to non-termination
--+-
  Reporter:  chak |  Owner: 
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone: 
 Component:  Compiler (Type checker)  |Version:  6.9
  Severity:  normal   |   Keywords: 
Difficulty:  Unknown  | Os:  Unknown
  Testcase:   |   Architecture:  Unknown
--+-
 This program sends the type checker to the land of no return:
 {{{
 {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
 {-# LANGUAGE FlexibleInstances, FlexibleContexts #-}

 module ShouldCompile where

 class E a b | a -> b, b -> a
 instance E a a

 plus :: (E a (Int -> Int)) => Int -> a
 plus x y = x + y
 }}}

-- 
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] #1241: Functional dependency Coverage Condition is lifted, and should not be

[GHC]

#1241: Functional dependency Coverage Condition is lifted, and should not be
+---
Reporter:  guest|Owner:
Type:  bug  |   Status:  new   
Priority:  normal   |Milestone:  6.8 branch
   Component:  Compiler (Type checker)  |  Version:  6.6   
Severity:  normal   |   Resolution:
Keywords:   |   Difficulty:  Unknown   
  Os:  Unknown  | Testcase:
Architecture:  Unknown  |  
+---
Comment (by simonpj):

 Here's an exchange I had with Martin Sulzmann a month or two back, but
 have not acted on.  It refines my informal proposal above.

 The current situation is this.  An instance decl must satisfy:

  1. The Paterson Conditions: for each assertion in the context
 * No type variable has more occurrences in the assertion than in the
 head
 * The assertion has fewer constructors and variables (taken together
 and counting repetitions) than the head
   1. The Coverage Condition. For each functional dependency, tvsleft ->
 tvsright, of the class, every type variable in S(tvsright) must appear in
 S(tvsleft), where S is the substitution mapping each type variable in the
 class declaration to the corresponding type in the instance declaration.

 See [http://www.haskell.org/ghc/dist/current/docs/users_guide/other-type-
 extensions.html#instance-rules  the GHC user manual instance rules]


 I propose to replace (2) with (2') namely:
   * EITHER The Coverage Condition (as written above)
   * OR
 A. The Refined Weak Coverage Condition. For each functional
 dependency, tvsleft -> tvsright, of the class, every type variable in
 S(tvsright) must be “reachable” from S(tvsleft), where S is <...text as
 before...>.  By “reachable” we mean “can be reached in a finite number of
 hops using the functional dependencies of the context of the instance
 decl” [I’ll formalise this more]
 B. AND the function dependencies of this class are full
 C. AND S(tvsright) are all type variables.

 Furthermore, if the programmer specifies `–fallow-undecidable-instances`
 (i.e  takes responsibility for termination) then we lift
   * the Paterson conditions
   * condition (C) above

 Throughout, I’m taking for granted the non-overlap of instance decls.

 Now my questions are these:
   * Is the above correct? That is guarantee confluence, termination.
 '''Martin''': YES

   * The either-or above is a bit unsatisfactory, because (A) relaxes one
 condition, but (B),(C) add new conditions.  Can you see any way to avoid
 that?  I’m guessing not.  '''Martin''': We definitely need some new
 conditions. (A) + (B) are sufficient and necessary conditions to guarantee
 confluence, assuming we have termination, (C) is sufficient to guarantee
 termination.  So, the answers is we cannot avaoid (A) + (B) but there
 might be further conditions (C') which guarantee termination.

   * Condition (C) is in our paper (Defn 14, page 30).  But if the Paterson
 conditions hold, is (C) necessary in addition?  '''Martin''': Yes! The
 Paterson conditions guarantee that the instances terminate. The subtle
 problem created by FDs is that type inference may not terminate (even if
 the instances terminate). We know that the coverage condition is also
 crucial for termination, but the refined weak coverage condition is only
 good enough to ensure confluence. Hence, we need the additional condition
 (C).

-- 
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: -O in 6.8.1-candidate

[Simon Peyton-Jones]

| By default cabal uses ghc -O to build projects, so you won't see any
| difference if you comment it out of the cabal file. You will however
| if you explicitly turn off optimisations:
|
| ghc-options: -Onot

This is perhaps a bit confusing. Is it documented in the cabal manual?  It's 
not documented under ghc-options in the currently-online manual.  Are there any 
other flags there by default?

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

Re: -O in 6.8.1-candidate

[Duncan Coutts]

On Wed, 2007-10-17 at 11:51 -0700, Don Stewart wrote:
> mechvel:
> > Dear GHC developers, 
> > 
> > Has  -O  any meaning in  ghc-6.8.1-candidate ?
> > 
> > I build  docon  under  ghc-6.8.1-candidate  under -O and 
> > with skipping it (the line of  -O  commented out in  docon.cabal). 
> > 
> > And it installs the .a library of the same size, 
> > and the test running takes the same time.
> > 
> 
> By default cabal uses ghc -O to build projects, so you won't see any
> difference if you comment it out of the cabal file. You will however
> if you explicitly turn off optimisations:
> 
> ghc-options: -Onot

or:

cabal-setup configure --disable-optimization

since the default is --enable-optimization which with ghc uses -O

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

Re: ghc for docon-2.10

[Ian Lynagh]

On Mon, Oct 15, 2007 at 10:10:12PM +0400, Serge D. Mechveliani wrote:
> 
> Dear GHC developers, please try any appropriate  ghc-6.8* candidate
> for making the public docon-2.10  and running its test module.

Looks good to me with 6.8.0.20071016.


Thanks
Ian

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

Re: bug in 6.8.1-candidate

[Ian Lynagh]

Hi Serge,

Thanks for the report!

On Sun, Sep 30, 2007 at 07:13:47PM +0400, Serge D. Mechveliani wrote:
> 
>   http://botik.ru/pub/local/Mechveliani/ghcBugs/bug-6.8.0-sep28.zip
> 
> 
> ... 
> 
> GBasFld_.hs: ...
> 
> ghc-6.8.0.20070928: panic! (the 'impossible' happened)
>   (GHC version 6.8.0.20070928 for i386-unknown-linux):
> initC: srt_lbl
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I believe this is now fixed; with 6.8.0.20071016:

[52 of 60] Compiling GBasFld_ ( GBasFld_.hs, dist/build/GBasFld_.o )
[53 of 60] Compiling GBasEuc_ ( GBasEuc_.hs, dist/build/GBasEuc_.o )

GBasEuc_.hs:40:15: Module `GBasFld_' does not export `cnAs_ev_'
[...]

Please let us know if you still have problems.


Thanks
Ian

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

[GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX

[GHC]

#1780: runInteractiveProcess broken with >2 processes on POSIX
---+
  Reporter:  guest |  Owner:   
  Type:  bug   | Status:  new  
  Priority:  normal|  Milestone:   
 Component:  Compiler  |Version:  6.6.1
  Severity:  normal|   Keywords:   
Difficulty:  Unknown   | Os:  Linux
  Testcase:|   Architecture:  x86  
---+
 Using runInteractiveProcess to build pipelines involving >2 processes
 doesn't work due to not closing enough FDs in the child post-fork.

 Initial problem report:
   http://news.gmane.org/find-
 root.php?group=gmane.comp.lang.haskell.cafe&article=30209

 Suggested fix:
   http://news.gmane.org/find-
 root.php?group=gmane.comp.lang.haskell.cafe&article=30241

-- 
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] #1779: unknown symbol `hs_hpc_module'

[GHC]

#1779: unknown symbol `hs_hpc_module'
+---
Reporter:  guest|Owner:  AndyGill
Type:  feature request  |   Status:  assigned
Priority:  low  |Milestone:  
   Component:  GHCi |  Version:  6.9 
Severity:  minor|   Resolution:  
Keywords:  hpc  |   Difficulty:  Unknown 
  Os:  Unknown  | Testcase:  
Architecture:  Unknown  |  
+---
Changes (by AndyGill):

  * status:  new => assigned
  * severity:  normal => minor
  * priority:  normal => low
  * owner:  => AndyGill
  * keywords:  => hpc
  * type:  bug => feature request

Comment:

 (unconfirmed) This happens when someone compilers a module with -fhpc,
 then uses ghci.
 ghci and hpc do not mix. A quick recompile fixes things.

 Perhaps fixed for ghc-6.9? We want to think about how we offer hpc inside
 ghci anyway,
 so I'll leave the feature request as a place holder.

-- 
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: -O in 6.8.1-candidate

[Serge D. Mechveliani]

To my question about  -O  in  ghc-6.8.1-candidate 
Don Stewart wrote on Wed, Oct 17

> By default cabal uses ghc -O to build projects, so you won't see any
> difference if you comment it out of the cabal file. You will however
> if you explicitly turn off optimisations:

I see now, thank you.


> I'd recommend using -O2 these days, particularly for a library like
> docon where performance matters. 
> 
> ghc-options: -O2


No,  -O2  is worse than  -O !

Build the public  docon  with  ghc-6.8.1-candidate   
under -O and under -O2.
Under -O2 
1) it is 10% larger and 10% longer to build,
2) demotest/Main  runs 10% slower.

And the following is close to a bug report:

cd demotest
ghc $doconCpOpt -O --make Main-- building docon test

compiles long and takes  900 Mb of RAM,
and after this I kill the process.

The same is for  ghc $doconCpOpt -O2 --make Main

I think, there is not any particular reason to compile the test under
-O, usually I apply -Onot here.
But still, this very long compilation and 900 Mb are suspicious.

Regards,

-
Serge Mechveliani
[EMAIL PROTECTED]


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

Re: -O in 6.8.1-candidate

[Don Stewart]

mechvel:
> Dear GHC developers, 
> 
> Has  -O  any meaning in  ghc-6.8.1-candidate ?
> 
> I build  docon  under  ghc-6.8.1-candidate  under -O and 
> with skipping it (the line of  -O  commented out in  docon.cabal). 
> 
> And it installs the .a library of the same size, 
> and the test running takes the same time.
> 

By default cabal uses ghc -O to build projects, so you won't see any
difference if you comment it out of the cabal file. You will however
if you explicitly turn off optimisations:

ghc-options: -Onot

I'd recommend using -O2 these days, particularly for a library like
docon where performance matters. 

ghc-options: -O2

For best results.

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

-O in 6.8.1-candidate

[Serge D. Mechveliani]

Dear GHC developers, 

Has  -O  any meaning in  ghc-6.8.1-candidate ?

I build  docon  under  ghc-6.8.1-candidate  under -O and 
with skipping it (the line of  -O  commented out in  docon.cabal). 

And it installs the .a library of the same size, 
and the test running takes the same time.

Regards,

-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: empty export warning

[Isaac Dupree]

Serge D. Mechveliani wrote:
People, 

here is a more precise report about empty _export_ in 
ghc-6.8.1-candidate:


I use
  
  module M1 (f, module M2)
  where
  import M2 ()
  f = ...
  

in the situation when  M1  imports some instances from  M2  and 
reexports these instances.


And  ghc-6.8.1-candidate  reports 


  "Warning: The export item `module M2' exports nothing"

1) Can I fix anything here?
2) Should this warning be different?


The warning is true.  The instances will be exported even if `module M2' 
is omitted from the export list, so that export item exports nothing.


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

Re: bug 1711 revisited

[Ian Lynagh]

Hi Hal,

On Tue, Oct 16, 2007 at 09:54:32PM -0700, Hal Perkins wrote:
> Sorry to revive a dead horse, but there's still a bit of a problem  
> with building ghc on os x because of missing files that need to be  
> created by happy.  I downloaded the current stable sources yesterday  
> (ghc-6.8.0.20071015-src.tar.bz2 and ghc-6.8.0.20071015-src- 
> extralibs.tar.bz2)

OK, ghc-6.8.0.20071015-src-extralibs.tar.bz2 definitely includes

libraries/haskell-src/Language/Haskell/Parser.hs

> Preprocessing library haskell-src-1.0.1...
> Setup: happy command not found
> make[1]: *** [haskell-src/GNUmakefile] Error 1

Does the above file still exist at this point?

If so, does
cd libraries
touch haskell-src/Language/Haskell/Parser.hs
make rebuild.library.haskell-src
work?

If that doesn't do it, what about if you delete
haskell-src/Language/Haskell/Parser.y
and then try
make rebuild.library.haskell-src
?


Thanks
Ian

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

empty export warning

[Serge D. Mechveliani]

People, 

here is a more precise report about empty _export_ in 
ghc-6.8.1-candidate:

I use
  
  module M1 (f, module M2)
  where
  import M2 ()
  f = ...
  

in the situation when  M1  imports some instances from  M2  and 
reexports these instances.

And  ghc-6.8.1-candidate  reports 

  "Warning: The export item `module M2' exports nothing"

1) Can I fix anything here?
2) Should this warning be different?

Regards,

-
Serge Mechveliani
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1540: GHC on Macs

[GHC]

#1540: GHC on Macs
-+--
Reporter:  guest |Owner:  thorkilnaur
Type:  task  |   Status:  new
Priority:  high  |Milestone:  6.8 branch 
   Component:  Build System  |  Version:  6.6.1  
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  MacOS X   | Testcase: 
Architecture:  x86   |  
-+--
Comment (by guest):

 I generate Mac binaries depending on the `GNUreadline` and `GMP`
 frameworks. I think, this happens automatically when these frameworks are
 installed under /Library/Frameworks.

 {{{
 otool -L hets
 hets:
 GNUreadline.framework/Versions/A/GNUreadline (compatibility
 version 5.0.0, current version 5.2.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 88.1.10)
 GMP.framework/Versions/A/GMP (compatibility version 8.0.0, current
 version 8.1.0)
 }}}

 If the frameworks are only under your home directory they allow running
 binaries, but for linking  extra flags are needed (i.e.
 `-F$HOME/Library/Frameworks -framework GMP`)

 I propose to link against these frameworks only, since unpacking the
 frameworks looks easier to me, but there may arise problems when different
 versions of these frameworks need to be handled.

 [EMAIL PROTECTED]

-- 
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] #1193: panic! addImpDecls in TH_dataD1 test

[GHC]

#1193: panic! addImpDecls in TH_dataD1 test
-+--
Reporter:  igloo |Owner:   
Type:  bug   |   Status:  closed   
Priority:  normal|Milestone:  6.6.2
   Component:  Template Haskell  |  Version:  6.6  
Severity:  normal|   Resolution:  fixed
Keywords:|   Difficulty:  Unknown  
  Os:  Unknown   | Testcase:  TH_dataD1
Architecture:  Unknown   |  
-+--
Changes (by simonpj):

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

Comment:

 This seems fixed in 6.6.1 and the HEAD so I'm closing it

 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

[GHC] #1779: unknown symbol `hs_hpc_module'

[GHC]

#1779: unknown symbol `hs_hpc_module'
--+-
  Reporter:  guest|  Owner: 
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone: 
 Component:  GHCi |Version:  6.9
  Severity:  normal   |   Keywords: 
Difficulty:  Unknown  | Os:  Unknown
  Testcase:   |   Architecture:  Unknown
--+-
 During a :load command I got:
 : /home/foo/Bar/Baz.o: unknown symbol `hs_hpc_module'

 No test case available

-- 
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] #1540: GHC on Macs

[GHC]

#1540: GHC on Macs
-+--
Reporter:  guest |Owner:  thorkilnaur
Type:  task  |   Status:  new
Priority:  high  |Milestone:  6.8 branch 
   Component:  Build System  |  Version:  6.6.1  
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  MacOS X   | Testcase: 
Architecture:  x86   |  
-+--
Comment (by guest):

 A couple more comments:

* Please don't use .pkgs such as used to be in the .dmgs. .pkg is a
 macOS installer format package, but there is no standard way to remove
 such packages! A package without a standard removal mechanism is horrible:
 where is the upgrade path?

* Not entirely unrelated to this is the issue of distributing a binary
 which has been compiled by ghc. This is similar because ghc itself is a
 binary compiled with ghc... The problem I observe is that the binaries I
 generate are dependent on finding a "macports-style" libgmp.so; because my
 GHC is macports-installed. This means that another mac user, who doesn't
 use macports, can't use my compiled binaries.

-- 
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: bug in 6.8.1-candidate

[Serge D. Mechveliani]

On Wed, Oct 17, 2007 at 12:35:08PM +0100, Simon Peyton-Jones wrote:
> Serge
> 
> I've just compiled docon-2.10 with the current 6.8 branch.  
> It compiles fine.  Log is below
> [..] 


Thank you.
I looked into the log that you have enclosed.

1. Instance import.

You see that GHC warns about a couple of modules imported but not used.
If I remove this import, it will report an error of not finding of a 
certain _instance_.
May be, this warning message must be improved? 

2. Running test.

Some 6.8* versions can do  make build  for  docon-2.10,  
but cannot `make' the test.
According to  install.txt,  the test has to do a bit more. 
This log is only for 
 make configure;  make build

And it is also needed to test this: 

   make install
   cd demotest
   ghc $doconCpOpt --make Main-- making and 
   ./Main +RTS -M60m -RTS -- running the DoCon test

(see  install.txt  about $doconOpts).
This test must report in the end of its log:  "no errors detected". 

3. Making ghc by ghc (by 6.6.1 and then, by itself). This must work.
   
4. Space.

It is desirable to test the space eagerness in comparison to ghc-6.6.1.
For example, if this  ./Main  running does not succeed within  -M50m,  
then this is suspicious.  

5. -Onot

As I recall, the default `make' for  docon  is under -O, and it is also 
desirable to test  -Onot  and repeat making and running ./Main.
Because users often like to build things under -Onot. 

6. Profiling  is a usable tool.

It is desirable to re-make DoCon under  -O  -prof -auto-all
(at least)
and print the pro-file for  -pT  for  demotest/Main  running.
For example, if it breaks, at any stage, or shows some strange time
per-centage, then GHC is buggy.


Usually I do all this myself.
-

And I can do this now as well --
if I know precisely 
1) where to take the needed  6.8-candidate  in source
2) that  ghc-6.6.1  can build this  6.8-candidate  from source.

But if the GHC developers do themself the points (1) - (6) 
for docon-2.10, I shall be grateful to them for saving my effort.

Regards,

---
Mechveliani



> I'm in docon-2.10/docon/source
> 
> bash-2.05b$ make configure
> runhaskell Setup.hs configure --ghc \
> 
> --with-compiler=/playpen/ghc/nightly/STABLE-cam-02-unx/i386-unknown-linux/compiler/stage2/ghc-inplace
>  \
>  
...
[..]

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

[GHC] #1778: Linux binary distributions only have one RTS way

[GHC]

#1778: Linux binary distributions only have one RTS way
---+
  Reporter:  simonmar  |  Owner: 
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone:  6.8.1  
 Component:  Build System  |Version:  6.6.1  
  Severity:  normal|   Keywords: 
Difficulty:  Unknown   | Os:  Unknown
  Testcase:|   Architecture:  Unknown
---+
 Just so we don't forget...

-- 
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] #1625: Windows installer: no Users guide or Cabal docs

[GHC]

#1625: Windows installer: no Users guide or Cabal docs
-+--
Reporter:  simonmar  |Owner:  igloo  
Type:  bug   |   Status:  new
Priority:  high  |Milestone:  6.8.1  
   Component:  Build System  |  Version:  6.6.1  
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Windows   | Testcase: 
Architecture:  Unknown   |  
-+--
Changes (by simonmar):

  * milestone:  6.8 branch => 6.8.1

-- 
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] #1709: simplifier causes stack overflow in ghc-6.8.0.20070916

[GHC]

#1709: simplifier causes stack overflow in ghc-6.8.0.20070916
-+--
Reporter:  [EMAIL PROTECTED]  |Owner:  simonpj
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  6.8.1  
   Component:  Compiler  |  Version:  6.8
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Linux | Testcase: 
Architecture:  x86   |  
-+--
Comment (by guest):

 ghc-6.8.0.20071016 is able to compile now all our uni- and hets- sources!
 Thanks again for taking the trouble of checking out, package modification
 and installation as well as tracking down the actual problem!

-- 
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