Re: [GHC] #820: problem compiling a file with top level Template Haskell splice
#820: problem compiling a file with top level Template Haskell splice ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.4.2 Component: Template Haskell |Version: 6.4.2 Severity: normal| Resolution: Keywords:| Os: Linux Difficulty: Unknown | Architecture: x86_64 (amd64) ---+ Comment (by Lemmih): I've been unable to reproduce this error with 6.4.2. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/820 GHC http://www.haskell.org/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] #826: Optimization breaks strictness with IO
#826: Optimization breaks strictness with IO -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 6.4.2 Severity: minor | Resolution: duplicate Keywords: | Os: Unknown Difficulty: Unknown | Architecture: Unknown -+-- Changes (by simonmar): * resolution: = duplicate * status: new = closed Comment: This looks like another instance of #457 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/826 GHC http://www.haskell.org/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
#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 -+-- Comment (by simonmar): See also #826 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/457 GHC http://www.haskell.org/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] #830: Compiler performance bug: large do expression
#830: Compiler performance bug: large do expression
-+--
Reporter: simonmar |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.4.2
Severity: normal| Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
-+--
From Neil Mitchell:
Using GHC 6.4.2 on Windows and 6.4.1 on Linux, I get really poor
compile time performance for large do blocks - for example:
{{{
main = do
return ()
return ()
return ()
}}}
The following are the compile times in seconds for a given number of
return () lines, GHC 6.4.1 on Linux, with a very beefy processor (my
department server) and loads of RAM.
{{{
1001.444
2004.054
3007.977
40013.967
50021.265
60030.71
70043.997
}}}
For comparison on my desktop machine I get out of heap space with
268Mb of heap, in a few minutes for 700. Compared to Hugs and Yhc,
which both deal with all of these files instantly.
By splitting the 700 line do block into 7 separate do blocks, each 100
lines, I get a compile time of 8.530.
The particular reason I was running into this issue was with an auto
generated file of tests, about 360 lines of reasonably lines in a do
block, which exhausted the memory in GHCi. I have modified my test
generator to split the files into 50 line blocks.
Thanks
Neil
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/830
GHC http://www.haskell.org/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] #830: Compiler performance bug: large do expression
#830: Compiler performance bug: large do expression ---+ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.4.2 Severity: normal| Resolution: Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonmar): * cc: = [EMAIL PROTECTED] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/830 GHC http://www.haskell.org/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] #831: GHCi user interface bug
#831: GHCi user interface bug +--- Reporter: guest|Owner: Type: bug | Status: new Priority: low |Milestone: Component: GHCi | Version: 6.4.2 Severity: minor| Keywords: Os: Windows | Difficulty: Unknown Architecture: x86 | +--- GHCi can do some weird things, with the letter g and the up arrow: ghci ghci :m Control.Concurrent ghci threadDelay 500 (now, while thread delay is running, press the up arrow once) (once the computation has returned, the following will be on the line) (i.e. you don't type threadDelay again) ghci threadDelay 500 (now just press enter) interactive:1:0: Not in scope: `ghreadDelay' This works for any computation that runs long enough for the user to press up while its still going. The result is always a g replacing the first letter - I have had gain for main etc. And the buffer always appears correct to visual inspection. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/831 GHC http://www.haskell.org/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] #831: GHCi user interface bug
#831: GHCi user interface bug --+- Reporter: guest| Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi |Version: 6.4.2 Severity: minor| Resolution: Keywords: | Os: Windows Difficulty: Unknown | Architecture: x86 --+- Comment (by guest): (WikiFormatting fixes) GHCi can do some weird things, with the letter g and the up arrow: ghci ghci :m Control.Concurrent ghci threadDelay 500 (now, while thread delay is running, press the up arrow once) (once the computation has returned, the following will be on the line) (i.e. you don't type threadDelay again) ghci threadDelay 500 (now just press enter) interactive:1:0: Not in scope: `ghreadDelay' This works for any computation that runs long enough for the user to press up while its still going. The result is always a g replacing the first letter - I have had gain for main etc. And the buffer always appears correct to visual inspection. -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/831 GHC http://www.haskell.org/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] #832: fermat numbers make the baby jesus cry.
#832: fermat numbers make the baby jesus cry. ---+ Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHCi| Version: 6.4.1 Severity: major | Keywords: Os: Windows | Difficulty: Unknown Architecture: x86 | ---+ when i run `Prelude 2 ^ (2 ^ 25) + (1::Integer)` in GHCi, after a few seconds: GHC caused a stack fault in module GHC.EXE at 017f:00c043d3. Registers: EAX=5120 CS=017f EIP=00c043d3 EFLGS=00010206 EBX=02502008 SS=0187 ESP=00fbdc88 EBP=00fbdca8 ECX=00dc1c90 DS=0187 ESI=00040001 FS=3377 EDX=00040001 ES=0187 EDI=00040001 GS= Bytes at CS:EIP: 83 09 00 2d 00 10 00 00 eb e9 29 c1 83 09 00 89 Stack dump: 02202008 00bfe5a6 0201 024fe008 00fbdd28 00bf64aa 0003 00040001 00fbdce8 00bfe8b9 02502008 02202008 00040001 00be51c9 0201 0003 (bigints from PLT scheme and ruby worked.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/832 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
regression: RULES not matching
Hi Simon, I think some recent patch has made some of my fusion rules stop matching. the test case is: foo = B.map (+1) . B.filter (/=0) with ghc 6.4.2 and with older versions of ghc-6.5 (May 26th): 5 RuleFired 2 int2Word# 2 narrow8Word# 1 strTransformerBi/strTransformerBi with my recent ghc 6.5 (Jul 24th) that strTransformer rule no longer fires. the rule is fairly simple: strTransformerBi/strTransformerBi forall f g s. strTransformerBi f (strTransformerBi g s) = strTransformerBi (f . g) s from looking at -ddump-simpl-iterations we get something interesting: Main.foo :: Data.ByteString.Base.ByteString - Data.ByteString.Base.ByteString [Exported] [Arity 1] Main.foo = \ (x_a1t7 :: Data.ByteString.Base.ByteString) - Data.ByteString.FusionStream.strTransformerBi1 (Data.ByteString.FusionStream.mapS1 a_s1tf) (Data.ByteString.FusionStream.strTransformerBi1 (Data.ByteString.FusionStream.filterS1 a_s1th) x_a1t7) This is exactly the form that should be matched by the rule, except.. what is this strTransformerBi1 ? with the '1' suffix? Where did that come from and is that what's causing the rule not to match? It's not there in 6.4.2. The full code is available: darcs get http://www.cse.unsw.edu.au/~dons/code/fps-unstable I'm just going to build ghc head and see if the issues still exists. This is a bit of a problem for Dons and me at the moment because we need a single version of ghc to use to benchmark our various fusion systems for a paper. We could go back to the May 26th version I suppose. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: regression: RULES not matching
On Wed, 2006-07-19 at 20:24 +0100, Duncan Coutts wrote: with my recent ghc 6.5 (Jul 24th) that strTransformer rule no longer fires. Sorry, that should have read July the 4th, not 24th! Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in GHC 6.4.1 and 6.4.2
According to a message from GHCi, version 6.4.1 (see below; bug also reproduceable with 6.4.2, though not shown here since it consistently resulted in a core dump without prior message) under Windows XP (fully updated per 2006-07-15), I am herewith reporting what appears to be a bug in GHC. Please see transcript below; the source file in question is included as an attachment. (Lacking both efficient Haskell programming skills and an understanding of the internals of GHC I have refrained from attempting to isolate the bug by reducing the code.) Should there be a simple work-around or something unsafe in my code (though I wouldn't know what: no unsafe operations are used; no polymorphism is present), I would greatly appreciate hearing about it. Sincerely, Fritz :load c:/henglein/Software/haskell/Basic.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude Compiling BasicDiscrimination ( c:/henglein/Software/haskell/Basic.hs, interpreted ) Ok, modules loaded: BasicDiscrimination. *BasicDiscrimination d - mkDiscriminator Loading package haskell98-1.0 ... linking ... done. *BasicDiscrimination res - d [(5, kdjfkd), (8, kjdkfjd)] interactive: internal error: EVACUATED object entered! Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ -- Fritz Henglein, Ph.D. Professor mso Dept. of Computer Science, University of Copenhagen (DIKU) Universitetsparken 1 DK-2100 Copenhagen Denmark Email: [EMAIL PROTECTED] Tel.: +45-35321463 (office), +45-41414158 (cell) Skype: henglein Basic.hs Description: Binary data ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in users manual, 6.4.2, section on pattern guards
One example given in this discussion is: clunky env var1 var1 = case lookup env var1 of Nothing - fail Just val1 - case lookup env var2 of Nothing - fail Just val2 - val1 + val2 where fail = val1 + val2 this needs to be fixed to: clunky env var1 var1 = case lookup env var1 of Nothing - fail Just val1 - case lookup env var2 of Nothing - fail Just val2 - val1 + val2 where fail = var1 + var2(Added for emphasis) I didn't see it myself on the first readthrough, but I was comparing structure between two examples and noticed the discrepency. Let's fix it for correctness' sake. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
compiler crash under MacOS X
hi, my very first tries with ghc, using the 'program' module Fact where fact :: Integer - Integer fact n = product [1..n] gave the following compiler crash under MacOS X 10.4.7 (ghc installed from source via DarwinPorts): Compiling Fact ( fact.hs, interpreted ) ghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 463 Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug more irritating, this error was _not_ reproducible. a second try did run through: `ghc -c fact.hs' yielded a file `fact.o' but `ghc -o fact fact.o' yielded: /usr/bin/ld: Undefined symbols: _ZCMain_main_closure ___stginit_ZCMain collect2: ld returned 1 exit status and `ghc -v --make fact' yielded Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /opt/local/lib/ghc-6.4.2/package.conf Using package config file: /Users/vdh/.ghc/powerpc-darwin-6.4.2/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: fact Stable modules: *** Compiling Fact ( fact.hs, fact.o ): compile: input file fact.hs *** Checking old interface for Fact: Skipping Fact ( fact.hs, fact.o ) *** Deleting temp files Deleting: /tmp/ghc18926.s Warning: deleting non-existent /tmp/ghc18926.s Upsweep completely successful. *** Deleting temp files Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files Deleting: what I got where two files `fact.o' and `fact.hi' (attached). hope this helps in one way or the other all the best joerg van den hoff fact.o Description: Binary data module Fact where fact :: Integer - Integer fact n = product [1..n] fact.hi Description: Binary data ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiler crash under MacOS X
Hi Joerg, This problem is almost certainly bug #751. This gives a compiler crash if the threaded run time system is used. The latest darwinports ghc (which I maintain) builds the run time without threads. What is the output of sudo port info ghc ? If you do not have revision 2 of the 6.4.2 portfile, you need to update: sudo port selfupdate If you are running the latest version, your experiences are... interesting. Best Wishes, Greg On Jul 17, 2006, at 5:36 AM, Joerg van den Hoff wrote: hi, my very first tries with ghc, using the 'program' module Fact where fact :: Integer - Integer fact n = product [1..n] gave the following compiler crash under MacOS X 10.4.7 (ghc installed from source via DarwinPorts): Compiling Fact ( fact.hs, interpreted ) ghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 463 Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug more irritating, this error was _not_ reproducible. a second try did run through: `ghc -c fact.hs' yielded a file `fact.o' but `ghc -o fact fact.o' yielded: /usr/bin/ld: Undefined symbols: _ZCMain_main_closure ___stginit_ZCMain collect2: ld returned 1 exit status and `ghc -v --make fact' yielded Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /opt/local/lib/ghc-6.4.2/package.conf Using package config file: /Users/vdh/.ghc/powerpc-darwin-6.4.2/ package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: fact Stable modules: *** Compiling Fact ( fact.hs, fact.o ): compile: input file fact.hs *** Checking old interface for Fact: Skipping Fact ( fact.hs, fact.o ) *** Deleting temp files Deleting: /tmp/ghc18926.s Warning: deleting non-existent /tmp/ghc18926.s Upsweep completely successful. *** Deleting temp files Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files Deleting: what I got where two files `fact.o' and `fact.hi' (attached). hope this helps in one way or the other all the best joerg van den hoff fact.o module Fact where fact :: Integer - Integer fact n = product [1..n] fact.hi ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
