RE: GHC Bug report
Two things to say.
First, you've said INLINE for both functions. GHC understands that as saying
replace a call to this function by the RHS that I'm writing right here. So
GHC doesn't optimise them much, if at all. It waits until it sees a call, then
inlines, then optimises *that*. So try calling 'firstnonspace' and see what
you get.
The only bad thing is that if you write (map firstnonspace xs), then there's no
visible call to firstnonspace, so the non-optimised version will get executed.
I'm in the middle of fixing that, with an upheaval 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 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 would like it if the Word8 could be passed without
boxing.
The full program text is here also in case the link above disappears:
\begin{code}
{-# LANGUAGE BangPatterns, MagicHash #-}
module Main where
import GHC.Word ( Word8(W8#) )
import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) )
import GHC.Prim ( indexWord8OffAddr#, (==#), (=#), (+#), word2Int#, Addr# )
isSpaceWord8 :: Word8 - Bool
isSpaceWord8 !w =
w == 0x20 ||-- ' '
w == 0x09 ||-- '\t'
w == 0x0A ||-- '\n'
w == 0x0D -- '\r'
{-# INLINE isSpaceWord8 #-}
firstnonspace :: Ptr Word8 - Int - Int - Int
firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m)
where
first :: Addr# - Int# - Int# - Int#
first addr n' m'
| n' =# m' = n'
| otherwise = if (not (isSpaceWord8 ch))
then n'
else first addr (n' +# 1#) m'
where
ch = W8# (indexWord8OffAddr# addr n')
{-# INLINE firstnonspace #-}
main = return ()
\end{code}
The output from ghc -O2 -ddump-simpl is:
\begin{core}
Tidy Core
Main.a :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.a =
\ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -
(# s_aHK, GHC.Unit.() #)
Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
Str: DmdType L]
Main.a1 =
GHC.TopHandler.a5
@ ()
(Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IOhttp://GHC.IOBase.IO ()))
Main.main :: GHC.IOBase.IOhttp://GHC.IOBase.IO ()
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.main =
Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IOhttp://GHC.IOBase.IO ())
Main.lit :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit = GHC.Word.W8# __word 13
Main.lit1 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit1 = GHC.Word.W8# __word 10
Main.lit2 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit2 = GHC.Word.W8# __word 9
Main.lit3 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit3 = GHC.Word.W8# __word 32
Main.isSpaceWord8 :: GHC.Word.Word8 - GHC.Bool.Bool
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(L)]
Main.isSpaceWord8 =
__inline_me (\ (w_ap1 :: GHC.Word.Word8) -
GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit3)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit2)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1
Main.lit
Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8
- GHC.Types.Inthttp://GHC.Types.Int
- GHC.Types.Inthttp://GHC.Types.Int
- GHC.Types.Inthttp://GHC.Types.Int
[GlobalId]
[Arity 3
NoCafRefs
Str: DmdType U(L)U(L)U(L)m]
Main.firstnonspace =
__inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8)
(ds1_dGb :: GHC.Types.Inthttp://GHC.Types.Int)
(ds2_dGc :: GHC.Types.Inthttp://GHC.Types.Int) -
case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -
case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -
case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -
letrec {
first_sH5 :: GHC.Prim.Addr#
- GHC.Prim.Int#http://GHC.Prim.Int
- GHC.Prim.Int#http://GHC.Prim.Int
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 would like it if the Word8 could be passed
without boxing.
The full program text is here also in case the link above disappears:
\begin{code}
{-# LANGUAGE BangPatterns, MagicHash #-}
module Main where
import GHC.Word ( Word8(W8#) )
import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) )
import GHC.Prim ( indexWord8OffAddr#, (==#), (=#), (+#), word2Int#, Addr# )
isSpaceWord8 :: Word8 - Bool
isSpaceWord8 !w =
w == 0x20 ||-- ' '
w == 0x09 ||-- '\t'
w == 0x0A ||-- '\n'
w == 0x0D -- '\r'
{-# INLINE isSpaceWord8 #-}
firstnonspace :: Ptr Word8 - Int - Int - Int
firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m)
where
first :: Addr# - Int# - Int# - Int#
first addr n' m'
| n' =# m' = n'
| otherwise = if (not (isSpaceWord8 ch))
then n'
else first addr (n' +# 1#) m'
where
ch = W8# (indexWord8OffAddr# addr n')
{-# INLINE firstnonspace #-}
main = return ()
\end{code}
The output from ghc -O2 -ddump-simpl is:
\begin{core}
Tidy Core
Main.a :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.a =
\ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -
(# s_aHK, GHC.Unit.() #)
Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
Str: DmdType L]
Main.a1 =
GHC.TopHandler.a5
@ ()
(Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IO ()))
Main.main :: GHC.IOBase.IO ()
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.main =
Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IO ())
Main.lit :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit = GHC.Word.W8# __word 13
Main.lit1 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit1 = GHC.Word.W8# __word 10
Main.lit2 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit2 = GHC.Word.W8# __word 9
Main.lit3 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit3 = GHC.Word.W8# __word 32
Main.isSpaceWord8 :: GHC.Word.Word8 - GHC.Bool.Bool
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(L)]
Main.isSpaceWord8 =
__inline_me (\ (w_ap1 :: GHC.Word.Word8) -
GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit3)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit2)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1
Main.lit
Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8
- GHC.Types.Int
- GHC.Types.Int
- GHC.Types.Int
[GlobalId]
[Arity 3
NoCafRefs
Str: DmdType U(L)U(L)U(L)m]
Main.firstnonspace =
__inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8)
(ds1_dGb :: GHC.Types.Int)
(ds2_dGc :: GHC.Types.Int) -
case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -
case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -
case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -
letrec {
first_sH5 :: GHC.Prim.Addr#
- GHC.Prim.Int#
- GHC.Prim.Int#
- GHC.Prim.Int#
[Arity 3
Str: DmdType LLL]
first_sH5 =
\ (addr_ape :: GHC.Prim.Addr#)
(n'_apg :: GHC.Prim.Int#)
(m'_api :: GHC.Prim.Int#) -
case GHC.Prim.=# n'_apg m'_api of wild3_XS {
GHC.Bool.False -
case GHC.Classes.not
(Main.isSpaceWord8
(GHC.Word.W8#
(GHC.Prim.indexWord8OffAddr# addr_ape n'_apg)))
of wild4_XU {
GHC.Bool.False - first_sH5 addr_ape
(GHC.Prim.+# n'_apg 1) m'_api;
GHC.Bool.True - n'_apg
};
GHC.Bool.True - n'_apg
}; } in
case first_sH5 p_ap6 n_ap8 m_apa of wild3_XN { __DEFAULT -
GHC.Types.I# wild3_XN
}
Re: [GHC] #3313: Uncertain bug report (panic!)
#3313: Uncertain bug report (panic!) --+- Reporter: semanticprecision |Owner: Type: bug| Status: closed Priority: normal |Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86| --+- Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: duplicate of #2881 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3313#comment:4 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] #3313: Uncertain bug report (panic!)
#3313: Uncertain bug report (panic!)
--+-
Reporter: semanticprecision |Owner:
Type: bug| Status: new
Priority: normal |Milestone: 6.12.1
Component: Compiler | Version: 6.10.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: x86|
--+-
Changes (by igloo):
* difficulty: = Unknown
* milestone: = 6.12.1
Comment:
Thanks for the report. It breaks the HEAD too.
Here's a minimal testcase:
{{{
module Foo where
import Data.Word
bytesToGrayscaleImage :: Word - Maybe ()
bytesToGrayscaleImage 5 = Just ()
bytesToGrayscaleImage 6 = Just ()
bytesToGrayscaleImage _ = Nothing
}}}
{{{
$ ghci Foo.hs
GHCi, version 6.11.20090710: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp-0.1.0.0 ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Foo ( Foo.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 6.11.20090710 for x86_64-unknown-linux):
schemeE(AnnCase).my_discr __word 5
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3313#comment:3
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] #3313: Uncertain bug report (panic!)
#3313: Uncertain bug report (panic!) --+- Reporter: semanticprecision | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 --+- Hi, I really have no clue what happened; ghc panic!'d without much info, as far as I can tell. I've attached the files I've been working with. In attempting `:l imageloader` in ghc, a panic! is achieved. That's about the extent of it. Everything was working fine (well, wan't compiling, but I ripped out the guts and was piecing it back together; but still, no crashing) until I changed the cast on line 26 of ImageLoader.hs. (I'm a Haskell n00b, hence the overtly inefficient and poorly-formatted code) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3313 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] #3313: Uncertain bug report (panic!)
#3313: Uncertain bug report (panic!)
---+
Reporter: semanticprecision | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal | Resolution:
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: x86
---+
Comment (by semanticprecision):
Additional info: Windows XP Home. Here's the actual error message:
{{{
Prelude Data.Word :l imageloader
[1 of 5] Compiling ArrayMethods ( ArrayMethods.hs, interpreted )
[2 of 5] Compiling Color( Color.hs, interpreted )
[3 of 5] Compiling Image( Image.hs, interpreted )
[4 of 5] Compiling GrayscalePNG ( GrayscalePNG.hs, interpreted )
[5 of 5] Compiling ImageLoader ( imageloader.hs, interpreted )
: panic! (the 'impossible' happened)
(GHC version 6.10.3 for i386-unknown-mingw32):
schemeE(AnnCase).my_discr __word 1
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
:q
Leaving GHCi.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3313#comment:1
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] #3313: Uncertain bug report (panic!)
#3313: Uncertain bug report (panic!)
---+
Reporter: semanticprecision | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal | Resolution:
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: x86
---+
Comment (by semanticprecision):
Replying to [comment:1 semanticprecision]:
More more info: bug was fixed by replacing
{{{
bytesToGrayscaleImage bytes 1 dimensions = Just ( listToImage (
byteStringToPixels bytes 1 color1 ) dimensions )
bytesToGrayscaleImage bytes 2 dimensions = Just ( listToImage (
byteStringToPixels bytes 2 color2 ) dimensions )
bytesToGrayscaleImage bytes 3 dimensions = Just ( listToImage (
byteStringToPixels bytes 3 color3 ) dimensions )
bytesToGrayscaleImage bytes 4 dimensions = Just ( listToImage (
byteStringToPixels bytes 4 color4 ) dimensions )
bytesToGrayscaleImage _ _ _ = Nothing
}}}
with
{{{
bytesToGrayscaleImage bytes depth dimensions
| depth == 1 = Just ( listToImage ( byteStringToPixels bytes 1
color1 ) dimensions )
| depth == 2 = Just ( listToImage ( byteStringToPixels bytes 2
color2 ) dimensions )
| depth == 3 = Just ( listToImage ( byteStringToPixels bytes 3
color3 ) dimensions )
| depth == 4 = Just ( listToImage ( byteStringToPixels bytes 4
color4 ) dimensions )
| otherwise = Nothing
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3313#comment:2
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: 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, teach normalizeTimeDiff to normalize tdPicoSeconds, too. This misfeature hangs around for too long :) Best regards, Andrei P.S. I'm not subscribed to the list, so please cc: me if needed. There are a number of serious problems with System.Time. If you're doing calculations involving time periods, I strongly suggest moving to the new time package (Data.Time etc.). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 to normalize tdPicoSeconds, too. This misfeature hangs around for too long :) Best regards, Andrei P.S. I'm not subscribed to the list, so please cc: me if needed. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 stops responding. I tried a new project and it worked perfectly. Then I added my files to this new project and it worked (I could build, rebuild, etc) until I closed it and reopened again, then trying to build just does not work (as with 0.0 projects). So I am leaning towards believing that I have something strange in my projects. My projects consists on all literate haskell files, a couple of alex and happy files. I also noticed some strange behaviour if I try to make Main a literate haskell file (an editing the cabal file). Now I am building from the command line but I miss the ability to build from the IDE :( Needless to say I loved this plugin. Regards, Roberto Lublinerman. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[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] http://bugs.darcs.net/issue168 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 more questions so that we have a chance to track down this bug: * Could you tell us what version of darcs that was? * What OS were you using? (eg Debian, Fedora, OS X, etc) * what kind of computer? (eg x86, x86_64) * Did you compile darcs yourself? if so version of GHC did you use? * Did you get darcs from a pre-compiled package? If so which one? * When you did annotate slice were you working with a very large repository or a small one? * Was the bug reproducible? Did it happen just the once or every time you ran that command? Thanks. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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/projects/ghc/ Would you mind answering a few more questions so that we have a chance to track down this bug: * Could you tell us what version of darcs that was? 1.0.5rc2 (release candidate ) * What OS were you using? (eg Debian, Fedora, OS X, etc) OSX 10.3.9 * what kind of computer? (eg x86, x86_64) G5 PPC * Did you compile darcs yourself? if so version of GHC did you use? I don't recall. * Did you get darcs from a pre-compiled package? If so which one? * When you did annotate slice were you working with a very large repository or a small one? large * Was the bug reproducible? Did it happen just the once or every time you ran that command? yes -- Steve ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 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
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/ghc/ I'm running Windows XP Service Pack 1. The only obvious thing from the run is that several generation 1 garbage collections resulted in a substantially smaller allocation than before (99% of all space was free over these two collections) and something bad happened. I've included the console data (trace output, the -Sstderr output, the parameters used to run the program, the OS version at the top...), as well as the code for the main module, the .hi file, and the .o file (in case these help). Neither the main module nor any of its included modules use FFI in any capacity. Use of unsafe IO is limited to caching and tracing. Note: the reference to threads solved, killed, etc. are to an abstraction of a DeductiveThread for a backtracking algorithm, which is the core logic of this program. No modules in this program use Control.Concurrent in any capacity. I'd be happy to provide additional details, additional source, etc. I'm going to rerun the program and see if the problem reoccurs: the program does use randomness, so it's possible that the problem won't appear again. The easiest way to contact me is at this email address. I check it regularly during the week, and periodically over the weekend. Please don't hesitate to ask if you have any questions, or if there's some other way I can help. I've quite enjoyed the GHC product, have written some significantly non-trivial programs using it, and would be happy to assist in making it a better and more robust tool. Thanks, and I look forward to hearing from you... oriel __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 On 07 December 2004 15:37, oriel maxime wrote: 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/ghc/ I'm running Windows XP Service Pack 1. The only obvious thing from the run is that several generation 1 garbage collections resulted in a substantially smaller allocation than before (99% of all space was free over these two collections) and something bad happened. I've included the console data (trace output, the -Sstderr output, the parameters used to run the program, the OS version at the top...), as well as the code for the main module, the .hi file, and the .o file (in case these help). Neither the main module nor any of its included modules use FFI in any capacity. Use of unsafe IO is limited to caching and tracing. Note: the reference to threads solved, killed, etc. are to an abstraction of a DeductiveThread for a backtracking algorithm, which is the core logic of this program. No modules in this program use Control.Concurrent in any capacity. I'd be happy to provide additional details, additional source, etc. I'm going to rerun the program and see if the problem reoccurs: the program does use randomness, so it's possible that the problem won't appear again. The easiest way to contact me is at this email address. I check it regularly during the week, and periodically over the weekend. Please don't hesitate to ask if you have any questions, or if there's some other way I can help. I've quite enjoyed the GHC product, have written some significantly non-trivial programs using it, and would be happy to assist in making it a better and more robust tool. Thanks, and I look forward to hearing from you... oriel __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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/.
today... definitely a but to do with class inference, as it started
appearing aftyer changing some instance constraints and fundeps on
classes.
Can't really be a lot more specific as code is big. Let me know if
you want
me to produce a small code extract which triggers it.
I'm not sure if anyone followed up on this... if you're still having the
problem, could you send us some code to reproduce?
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 started appearing
aftyer changing some instance constraints and fundeps on classes.
Can't really be a lot more specific as code is big. Let me know if you want
me to produce a small code extract which triggers it.
Regards,
Keean.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 [pkg>]GHCziErr Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Pierre Valarcher LIFAR - Université de Rouen 76821 Mont Saint-Aignan Cédex mailto:[EMAIL PROTECTED]
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, but I can't. It happens when I am building a (buddha-transformed) raytracer which I am also trying to profile (there is a lot of code involved - and it is mangled because of the debugging transformation, so finding a simplified expression of the bug is somewhat tricky). The bug disappears if I re-compile all my code from scratch. In any case the code for zip_ty_env is simple enough that someone who understands it may want to consider its assumptions: zip_ty_env [] [] env = env zip_ty_env (tv:tvs) (ty:tys) env = Obviously one of the lists is empty and the other is not - though the code assumes this will never happen. Cheers, Bernie. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 don't think it was reported on the lists, so you can be forgiven for not having seen it!). The workaround is to avoid using the 'a' and 'g' flags to Happy, or to compile the parser using GHC before loading it into GHCi. The bug was fixed in the HEAD, but was deemed to difficult to fix in the 5.04.x branch too. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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
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-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 inclined to consider the request for report to be the real bug here. Unknown opt(imization) level says it all, I think. Perhaps lower to the highest possible (-O2) when overspecified like this? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 -RTS Heap exhausted; Current maximum heap size is 299008 bytes; Maybe, my earlier complex bug report will become unnecessary after this small one is fixed. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 -M100k -RTS 99001 ./run +RTS -M300k -RTS Heap exhausted; Current maximum heap size is 299008 bytes; This is a minor mishap in the heap size calculations, caused by the fact that the maximum heap size you specified in the first test (100k) is smaller than the minimum allocation area size (256k). I've fixed the bug, it should at least report a heap-size exhaustion in both cases. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: compiler bug report
What platform is this on? I've had reports of wierdnesses with the sparc-solaris binary build we made for 5.00.2 which don't happen in the Linux builds. J | -Original Message- | From: Hal Daume [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, August 01, 2001 6:57 PM | To: Simon 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... | | - Hal | | Simon Marlow wrote: | | 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 can provide that will help us to | repro it? | | Cheers, | Simon | | 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/ | \/\/ /_/\/|_| Type :? for help. | | Loading package std ... linking ... done. | Loading package lang ... linking ... done. | Prelude :l Util | :l Util | Skipping Util ( Util.hs, ./Util.o ) | Ok, modules loaded: Util. | Util List.[] | List.[] | | Ambiguous type variable(s) `t' in the constraint | `PrelShow.Show t' | arising from use of `PrelIO.print' at No locn in a `do' | expression | pattern binding: PrelIO.print it | Util `eq` | `eq` | no file:0: parse error on input ``' | Util 3 `eq` 4 | 3 `eq` 4 | | no file:0: Variable not in scope: `eq' | Util :l Util | :l Util | unloadObj: can't find `./Util.o' to unload | ghc-5.00.2: panic! (the `impossible' happened, GHC | version 5.00.2): | unloadObj: failed | | Please report it as a compiler bug to | [EMAIL PROTECTED], or | http://sourceforge.net/projects/ghc/. | | | Util | - | | I'm not sure exactly what went wrong, but here's a copy of | Util.hs... | | -- | Hal Daume III | |Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | | www.isi.edu/~hdaume | | | -- | Hal Daume III | | Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgo| w-haskell-bugs | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 can provide that will help us to repro it? Cheers, Simon 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/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Prelude :l Util :l Util Skipping Util ( Util.hs, ./Util.o ) Ok, modules loaded: Util. Util List.[] List.[] Ambiguous type variable(s) `t' in the constraint `PrelShow.Show t' arising from use of `PrelIO.print' at No locn in a `do' expression pattern binding: PrelIO.print it Util `eq` `eq` no file:0: parse error on input ``' Util 3 `eq` 4 3 `eq` 4 no file:0: Variable not in scope: `eq' Util :l Util :l Util unloadObj: can't find `./Util.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Util - I'm not sure exactly what went wrong, but here's a copy of Util.hs... -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: compiler bug report
I just thought I'd point out: this is the third report of similar behaviour, so there's clearly something amiss. If anyone else has seen it and/or has any clues as to how we might track it down, please speak up. Cheers, Simon -Original Message- From: Simon 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 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 can provide that will help us to repro it? Cheers, Simon 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/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Prelude :l Util :l Util Skipping Util ( Util.hs, ./Util.o ) Ok, modules loaded: Util. Util List.[] List.[] Ambiguous type variable(s) `t' in the constraint `PrelShow.Show t' arising from use of `PrelIO.print' at No locn in a `do' expression pattern binding: PrelIO.print it Util `eq` `eq` no file:0: parse error on input ``' Util 3 `eq` 4 3 `eq` 4 no file:0: Variable not in scope: `eq' Util :l Util :l Util unloadObj: can't find `./Util.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Util - I'm not sure exactly what went wrong, but here's a copy of Util.hs... -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 - 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 can provide that will help us to repro it? Cheers, Simon 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/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Prelude :l Util :l Util Skipping Util ( Util.hs, ./Util.o ) Ok, modules loaded: Util. Util List.[] List.[] Ambiguous type variable(s) `t' in the constraint `PrelShow.Show t' arising from use of `PrelIO.print' at No locn in a `do' expression pattern binding: PrelIO.print it Util `eq` `eq` no file:0: parse error on input ``' Util 3 `eq` 4 3 `eq` 4 no file:0: Variable not in scope: `eq' Util :l Util :l Util unloadObj: can't find `./Util.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Util - I'm not sure exactly what went wrong, but here's a copy of Util.hs... -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Prelude :l Util :l Util Skipping Util ( Util.hs, ./Util.o ) Ok, modules loaded: Util. Util List.[] List.[] Ambiguous type variable(s) `t' in the constraint `PrelShow.Show t' arising from use of `PrelIO.print' at No locn in a `do' expression pattern binding: PrelIO.print it Util `eq` `eq` no file:0: parse error on input ``' Util 3 `eq` 4 3 `eq` 4 no file:0: Variable not in scope: `eq' Util :l Util :l Util unloadObj: can't find `./Util.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Util - I'm not sure exactly what went wrong, but here's a copy of Util.hs... -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume module Util where import List import Maybe import Char import IO import IOExts infix != a != b = not (a == b) nth [] i = error (nth out of range: ++ (show i)) nth (x:_) 1 = x nth (_:x) (n+1) = nth x n containsFn f l = isJust (find f l) contains x = containsFn (==x) mapPartial :: (a - Maybe b) - [a] - [b] mapPartial f l = mapPartial' f l [] where mapPartial' _ [] acc = acc mapPartial' f (x:xs) acc = mapPartial' f xs (case f x of Nothing - acc Just x' - x':acc) -- same as otherwise ow = True foldMaybe :: (a - b - Maybe a) - a - [b] - Maybe a foldMaybe _ a [] = Just a foldMaybe f a (b:bs) = case f a b of Nothing - Nothing Just a' - foldMaybe f a' bs allButLast :: [a] - [a] allButLast [] = error allButLast on [] allButLast [x] = [] allButLast (x:xs) = x:allButLast xs putErr s = unsafePerformIO (do hPutStrLn stderr s) maybeGood Nothing = Error maybeGood maybeGood (Just a) = Good a goodMaybe (Error _) = Nothing goodMaybe (Good a) = Just a infixr 9 ===, =~= good (Good a) = a good (Error err) = error err class LCaseEq a where (===) :: a - a - Bool instance LCaseEq Char where c1 === c2 = toLower c1 == toLower c2 instance LCaseEq a = LCaseEq [a] where [] === [] = True [] === _ = False _ === [] = False (c:cs) === (c':cs') = c === c' cs === cs' class Approx a where (=~=) :: a - a - Bool instance Eq a = Approx [a] where a =~= b = take 50 a == take 50 b data Errored a = Good a | Error String deriving (Eq, Show, Ord, Read) isNum x = isAlphaNum x (not (isAlpha x)) --beginsWithBy abc abcd (==) = True --beginsWithBy abc ab (==) = False beginWithBy _ [] _ = True beginWithBy _ _ [] = False beginWithBy eq (x:xs) (y:ys) | x `eq` y = beginWithBy xs ys eq | otherwise = False beginWith = beginWithBy (==)
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: == $ ghc -i/does_not_exist -c H.hs WARNING: error while reading directory /does_not_exist H.hs:2: failed to load interface for `DoesNotExistEither': Could not find interface file for `DoesNotExistEither' == Dependency generation crashes: == $ ghc -i/does_not_exist -M H.hs ghc-5.00: panic! (the `impossible' happened, GHC version 5.00): does not exist Action: getDirectoryContents Reason: No such file or directory Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. == Fix: the existence check in compiler/main/DriverMkDepend.hs, lines 114ff should not be omitted. This patch should do the trick (borrowed from Finder.lhs): == cvs server: Diffing . Index: DriverMkDepend.hs === RCS file: /cvs/fptools/ghc/compiler/main/DriverMkDepend.hs,v retrieving revision 1.9 diff -u -H -w -B -b -r1.9 DriverMkDepend.hs --- DriverMkDepend.hs 2001/03/28 16:51:03 1.9 +++ DriverMkDepend.hs 2001/04/26 11:34:30 @@ -113,8 +113,8 @@ -- reference. import_dirs - readIORef v_Import_paths pkg_import_dirs - getPackageImportPath - import_dir_contents - mapM getDirectoryContents import_dirs - pkg_import_dir_contents - mapM getDirectoryContents pkg_import_dirs + import_dir_contents - mapM getDirectoryContents' import_dirs + pkg_import_dir_contents - mapM getDirectoryContents' pkg_import_dirs writeIORef v_Dep_dir_contents (zip import_dirs import_dir_contents ++ zip pkg_import_dirs pkg_import_dir_contents) @@ -199,4 +199,11 @@ -- in search dir_contents + +getDirectoryContents' d + = IO.catch (getDirectoryContents d) + (\_ - do hPutStr stderr + (WARNING: error while reading directory ++ d) + return [] + ) == regards, Matthias -- Matthias Fischmann | Research Engineer| +358 (9) 8565 7474 [EMAIL PROTECTED] | SSH Communication Security Corp. | +358 (40) 752 5291 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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/glasgow-haskell-bugs
RE: Bug report
Axel
Quite right; thank you for reporting it. The fix was trivial, but
we're not planning 4.08.2 for a while (if ever). So a workaround is to
write
import PrelIOBase
foo = returnIO
in your module. Or have at least one 'foreign export dynamic' in your
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
| -- (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 ghc (ghc -v in attachment) :
| -- panic! (the `impossible' happened):
| --tcLookupGlobalValue: THIS.PrelIOBase.returnIO{-0B,s-}
| --Please report it as a compiler bug to
| [EMAIL PROTECTED]
|
| module Main where
|
| import Foreign
|
| foreign export ccall "gccd" mygcd :: Int - Int - Int
| main =
| do
| putStrLn "No bug"
|
| mygcd a b = if (a==b) then a
| else if (ab) then mygcd a (b-a)
| else mygcd (a-b) a
|
|
|
| -- Bye Axel
|
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
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 ghc (ghc -v in attachment) :
-- panic! (the `impossible' happened):
-- tcLookupGlobalValue: THIS.PrelIOBase.returnIO{-0B,s-}
--Please report it as a compiler bug to [EMAIL PROTECTED]
module Main where
import Foreign
foreign export ccall "gccd" mygcd :: Int - Int - Int
main =
do
putStrLn "No bug"
mygcd a b = if (a==b) then a
else if (ab) then mygcd a (b-a)
else mygcd (a-b) a
-- Bye Axel
The Glorious Glasgow Haskell Compilation System, version 4.08.1
Effective command line: -v -fglasgow-exts
-i/home/cip/krauth//lib/ghc-4.08.1/imports/lang/ -o bug -lHSlang
Ineffective C pre-processor:
echo '{-# LINE 1 "bug.hs" -}' /tmp/ghc7909.cpp cat bug.hs
/tmp/ghc7909.cpp
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (107major+15minor)pagefaults 0swaps
ghc:compile:Output file bug.o doesn't exist
ghc:compile:Interface file bug.hi doesn't exist
ghc:recompile:Input file bug.hs newer than bug.o
Haskell compiler:
/home/cip/krauth//lib/ghc-4.08.1/hsc /tmp/ghc7909.cpp -fglasgow-exts
-fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [
-fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods
-fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi-version=408
-static
"-himap=/home/cip/krauth//lib/ghc-4.08.1/imports/lang/%.hi:.%.hi:/home/cip/krauth//lib/ghc-4.08.1/imports/lang%.hi:/home/cip/krauth//lib/ghc-4.08.1/imports/lang%.hi:/home/cip/krauth//lib/ghc-4.08.1/imports/std%.hi"
"-himap-sep=:"-v -hifile=/tmp/ghc7909.hi -olang=asm -ofile=/tmp/ghc7909.s
-F=/tmp/ghc7909_stb.c -FH=/tmp/ghc7909_stb.h +RTS -H600 -K100
Glasgow Haskell Compiler, version 4.08, for Haskell 98, compiled by GHC version 4.08
panic! (the `impossible' happened):
tcLookupGlobalValue: THIS.PrelIOBase.returnIO{-0B,s-}
Please report it as a compiler bug to [EMAIL PROTECTED]
Command exited with non-zero status 1
0.89user 0.06system 0:01.00elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1344major+1811minor)pagefaults 0swaps
deleting... /tmp/ghc7909.cpp /tmp/ghc7909.hi /tmp/ghc7909.s /tmp/ghc7909_stb.c
/tmp/ghc7909_stb.h
rm -f /tmp/ghc7909*
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 annotations were added in a file containing
type and data definitions only. The compilation
of that file went fine. The compilation of another
one depending on the types went wrong:-(
I have attached a log.
Let me know if you need some more info.
Regards,
Marc van Dongen
--
Marc van Dongen, CS Dept | phone: +353 21 4903578
University College Cork, NUIC | Fax:+353 21 4903113
College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
ghc-4.08 -prof -auto-all -H20M -recomp -v -fglasgow-exts -cpp -hi-diffs -syslib posix
-syslib util -fvia-C -fno-update-analysis -optC-fallow-overlapping-instances
-funbox-strict-fields -fno-prune-tydecls -fno-prune-instdecls -ddump-rules
-ddump-simpl-stats -O2 -c PSearch.lhs
The Glorious Glasgow Haskell Compilation System, version 4.08
literate pre-processor:
echo '#line 1 "PSearch.lhs"' /tmp/ghc18636.lpp
/usr/local/lib/ghc-4.08/unlit PSearch.lhs - /tmp/ghc18636.lpp
real0.0
user0.0
sys 0.0
Effective command line: -prof -auto-all -H20M -recomp -v -fglasgow-exts -cpp -hi-diffs
-syslib posix -syslib util -fvia-C -fno-update-analysis
-optC-fallow-overlapping-instances -funbox-strict-fields -fno-prune-tydecls
-fno-prune-instdecls -ddump-rules -ddump-simpl-stats -O2 -c
Haskellised C pre-processor:
echo '{-# LINE 1 "PSearch.lhs" -}' /tmp/ghc18636.cpp
/usr/local/lib/ghc-4.08/hscpp -v '-DPROFILING' -D__HASKELL__=98 -D__HASKELL1__=5
-D__GLASGOW_HASKELL__=408 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -I.
-I/usr/local/lib/ghc-4.08/includes /tmp/ghc18636.lpp /tmp/ghc18636.cpp
real0.0
user0.0
sys 0.0
hscpp:CPP invoked: gcc -E -undef -traditional -DPROFILING -D__HASKELL__=98
-D__HASKELL1__=5 -D__GLASGOW_HASKELL__=408 -D__HASKELL98__ -D__CONCURRENT_HASKELL__
-I. -I/usr/local/lib/ghc-4.08/includes - /tmp/ghc18636.lpp
ghc-4.08:recompile:Input file PSearch.lhs newer than PSearch.o
Haskell compiler:
/usr/local/lib/ghc-4.08/hsc /tmp/ghc18636.cpp -fglasgow-exts
-fallow-overlapping-instances -funbox-strict-fields -fno-prune-tydecls
-fno-prune-instdecls -ddump-rules -ddump-simpl-stats -fauto-sccs-on-all-toplevs
-fscc-profiling -ffoldr-build-on -fdo-eta-reduction -fdo-lambda-eta-expansion
-fcase-of-case -fcase-merge -flet-to-case -fpedantic-bottoms -fsimplify [
-finline-phase0 -fno-rules -fno-case-of-case -fmax-simplifier-iterations2 ]
-fspecialise -ffloat-outwards -ffloat-inwards -fsimplify [ -finline-phase1
-fmax-simplifier-iterations4 ] -fsimplify [ -finline-phase2
-fmax-simplifier-iterations2 ] -fsimplify [ -fmax-simplifier-iterations2 ]
-fstrictness -fcpr-analyse -fworker-wrapper -fsimplify [ -fmax-simplifier-iterations4
] -ffloat-outwards -fcse -ffloat-inwards -fsimplify [ -fmax-simplifier-iterations4 ]
-fmassage-stg-for-profiling -flet-no-escape -fwarn-overlapping-patterns
-fwarn-missing-methods -fwarn-missing-fields -fwarn-deprecations
-fwarn-duplicate-exports -fhi!
-version=408 -static
"-himap=.%.hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/concurrent%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/util%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/concurrent%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/util%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/posix%.p_hi:/usr/local/lib/ghc-4.08/imports/lang%.p_hi:/usr/local/lib/ghc-4.08/imports/std%.p_hi"
"-himap-sep=:"-v -hifile=/tmp/ghc18636.hi -olang=C -ofile=/tmp/ghc18636.hc
-F=/tmp/ghc18636_stb.c -FH=/tmp/ghc18636_stb!
.h +RTS -H2000 -K100
Glasgow Haskell Compiler, version 4.08, for Haskell 98, compiled by GHC version 4.08
Transformation rules
Top-level specialisations
FloatOut stats:
322 Lets floated to top level; 40 Lets floated elsewhere; from 287 Lambda groups
Strictness analysis statistics
Lambda vars: 0/0; Case vars: 218/661; Let vars: 29/232
FloatOut stats:
18 Lets floated to top level; 3 Lets floated elsewhere; from 203 Lambda groups
Grand total simplifier statistics
Total
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: Pattern match(es) are overlapped in a group of case alternatives beginning a: b - ... c - ... You're not an Erlang programmer by any chance are you? :-) As Kevin pointed out, the warning is correct. In Haskell, a variable name in a pattern is always a new binding, and shadows any existing bindings of the same name. Cheers, Simon
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 group of case alternatives beginning a: b - ... c - ... The program may be wrong. (Is this legal?). But the error message certainly is wrong. bye
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 will always succeed. Hence the warning from GHC. I'm not sure that GHC could, in general, produce a better error message. regards Kevin Volker Wysk writes: 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 group of case alternatives beginning a: b - ... c - ... The program may be wrong. (Is this legal?). But the error message certainly is wrong. bye
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/includes /usr/local/include /usr/local/sparc-sun-solaris2.5/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/include /usr/include End of search list. /usr/local/ghc-4.00/lib/ghc-4.00/includes/ClosureMacros.h:140: unterminated character constant /usr/local/ghc-4.00/lib/ghc-4.00/includes/StgMacros.h:87: unterminated string or character constant real0.3 user0.2 sys 0.0 deleting... /tmp/ghc6070.cpp /tmp/ghc6070.hi /tmp/ghc6070.hc /tmp/ghc6070_stb.c /tmp/ghc6070_stb.h ghc6070.c ghc6070.s /tmp/ghc6070_o.s rm -f /tmp/ghc6070* make: *** [Result.o] Error 1 Needless to say I haven't changed ClosereMacros.h or StgMacros.h Any suggestions how to fix this? Regards, Marc
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.00/includes /usr/local/include /usr/local/sparc-sun-solaris2.5/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/include /usr/include End of search list. /usr/local/ghc-4.00/lib/ghc-4.00/includes/ClosureMacros.h:140: unterminated character constant /usr/local/ghc-4.00/lib/ghc-4.00/includes/StgMacros.h:87: unterminated string or character constant real0.3 user0.2 sys 0.0 deleting... /tmp/ghc6070.cpp /tmp/ghc6070.hi /tmp/ghc6070.hc /tmp/ghc6070_stb.c /tmp/ghc6070_stb.h ghc6070.c ghc6070.s /tmp/ghc6070_o.s rm -f /tmp/ghc6070* make: *** [Result.o] Error 1 Are you passing any extra flags to GHC? Could you send a copy of the file and a full transcript of the compilation with '-v' please. Cheers, Simon -- Simon Marlow Microsoft Research Ltd., Cambridge, U.K.
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 my question from 27 Jan 98 and Sigbjorn's reply on 28 Jan 98 in the mailing list archive. -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
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_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]
- c_trKD
Thanks for the report, this looks suspiciously similar to the panic
reported by Sven a couple of days ago (I attach Simon's reply to it.)
Bottom line: try compiling the module with -fno-update-analysis and
see if that side steps it.
--Sigbjorn
Simon L Peyton Jones writes:
One can play funny games with GHC-3.00 and the following program
(a small fragment of a Happy-generated parser):
--
module Foo ( happyParse ) where
action_0 1 = \j tk _ - action_1 j j tk (HappyState action_1)
action_1 3 = error "Bar"
action_1 _ = \i tk st@(HappyState action) sts stk - action (-1) (-1) tk st sts
(Just i : stk)
happyParse = action_0 2 2 '-' (HappyState action_0) [] [] 2
newtype HappyState b c =
HappyState (Int - Int - b - HappyState b c - [HappyState b c] - c)
--
Great program! Thanks for isolating it.
Simon: pls add to regression suite
There are two problems. One is a long-standing bit of grubbiness
in the code generator; hence fun_result_ty panic. I've fixed that
(still grubbily, I fear).
GHC goes into a loop in the update analyser. Reason: the
recursive contravariance of HappyState. Consider:
action_1 j j tk (HappyState action_1) sts stk
= {unfold action_1}
action_1 (-1) (-1) tk (HappyState action_1) sts (Just j:stk)
= {unfold action_1 again}
...
Neither action_0 nor action_1 is recursive, but infinite unfolding
can still occur. This can cause the simplifier to loop, though
on this occasion it doesn't, but only because action_1 is
considered too big to unfold. But it does make the update analyser
loop, for some obscure reason. It wouldn't surprise me if the
strictness analyser looped too, but it doesn't.
For some reason there's no flag to switch off the update analyser.
It does very little good anyway, so just switch it off by force
in ghc/driver/ghc.lprl (look for -fupdate-anal).
I've known about the possibility of looping in the simpifier for some time, but
never seen it in a real program. I have no idea how to spot it in a clean way,
and without disabling lots of useful inlining. (I prevent looping mainly by
treating letrec carefully.) Ideas welcome
Simon
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]
- c_trKD
Thanks for the report, this looks suspiciously similar to the panic
reported by Sven a couple of days ago (I attach Simon's reply to it.)
Bottom line: try compiling the module with -fno-update-analysis and
see if that side steps it.
Not so. It was this problem:
There are two problems. One is a long-standing bit of grubbiness
in the code generator; hence fun_result_ty panic. I've fixed that
(still grubbily, I fear).
I didn't produce a patch because I fixed it by modifying a number
of files in a tidy-up effort. Yell if this is a show-stopper for you
and we'll accelerate a fixed 3.0
S
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 has more details.
Offending type:
Residue.ResidueG{-rHG-} (Pol.Polynomial{-rHB-} $x0_ts1Kze $x1_ts1Kzd)
-
Group_.Subgroup{-rD3-} (Residue.ResidueG{-rHG-} (Pol.Polynomial{-rHB-} $x0_ts1Kze
$x1_ts1Kzd)) PrelBase.Integer{-3g-}
If more details are needed please call.
Regards,
Marc van dongen
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, but that's what was so neat about ghc-2.** : they allowed types here. 3.0 is more consistent here. Suppose I write show (Blah,3) should that show as a Tuple or as a (Blah,Int) pair? What if it was (Show (Blah,3)::Tuple)? Etc. Essentially, resolving overloading is incoherent if you allow overlapping instance decls. 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) where .. instance C (Int,Int) where .. instance C (Blah, Bool) where ... since none of these overlap. But Show does have an instance for (a,b) so you are stuck. By "overlap" I mean that the instance types can be unified. Einar says: With the good old 2.something compiler, I could overwrite the default definition of Show for lists and other type constructors, e.g.: data Blah = Blah deriving (Read,Show) instance Show [Blah] where showsPrec d [] r = r showsPrec d _ r = "bla bla ..." ++ r Duplicate or overlapping instance declarations for `Show [Blah]' at PrelBase.mc_hi and Blah.hs Same issue. Show [a] exists already and overlaps with Show [Blah]. There is a full discussion of the bad consequences of overlapping instance decls in the multi-parameter type class paper http://www.dcs.gla.ac.uk/~simonpj/multi.ps.gz 3.0 is a bit more restrictive than 2.xx, but it is Righter I think. Dissenting opinions welcome. Simon
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 system, so we're not going to expend a great deal of effort on fixing bugs in the old one. Try varying the heap size and changing the location of cost-centres, and see if the problem goes away. In both cases I was running with a +RTS -PT -RTS run-time option. Serial time profiles (the -P option) probably don't work, and are of dubious utility in any case - I'd be interested to know if the problem goes away if you use -p instead of -P. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
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 wanted. No idea, could you provide a test case please? Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
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 one, you have to be sure to remove the old one first, or you might stomp on the ghc-2.09 link too... Having created such links by hand, I can report that the install script doesn't appear to thusly stomp. I guess it'd do so if it changed the file contents, rather than the handle, but don't quote me on the details of this, as I haven't investigated the details of what the script does... Either hard or symbolic is fine by me, mind you. Cheers, Alex.
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 installed from the build tree when doing 'make install'. Will fix. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
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 /usr/local/ghc-2.09/lib/libHS.a(GHCmain__7.o) I have not used the function getBufferMode in my source. I do have a hSetBuffering. Any suggestions how to get around this? Thanks in advance, Marc van Dongen
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 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 makefile this should be happening, either, but as I said, ah dinnae ken GHC makefiles... This is so that you can install the new version over the older version. Why not make it a "hard" link, in the same directory, thereby making the point of which one is the real one moot? Cheers, Alex.
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 /usr/local/ghc-2.09/lib/libHS.a(IOHandle__131.o) Main_main_closure /usr/local/ghc-2.09/lib/libHS.a(GHCmain__7.o) This is another file missing from the source distribution. The new one is now up, and it contains all the necessary files. Sorry for any inconvenience. -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
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 :: (a,b,c) - a first (a,b,c) = a Stange.lhs:5: Couldn't match the type `PrelTup.(,,) tazz' against `PrelTup.(,)' Expected: `(tazz, tazz, tazz)' Inferred: `(tazz, tazN)' In a list-comprehension qualifer: `(first triple) PrelBase.== (PrelTup.fst triple)' Hope this helps, Marc van Dongen [EMAIL PROTECTED]
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 a) where (==) e1 e2 = True instance (Class a) = Ord (L a) where compare a b = EQ instance (Class a) = Num (L a) where negate p = p instance (Class a) = Show (L a) where showsPrec _ _ c = c instance (Class a) = Read (L a) where readsPrec _ _ = [(L [],[])] buggy :: (Class a) = (L a) - (L a) buggy omega = g omega 1 g :: (Class a) = (L a) - a - (L a) g omega one = omega I had expected an overloading error because of the use of ``1'' in the definition for ``buggy''. Hope this helps. Regards, Marc van Dongen
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_DICTsBlah2.o CC_nubZ92Zq_struct Blah4.o ld: fatal: Symbol referencing errors. No output written to Blah Hope this helps. Regards, Marc
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)
| 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 patterns in the definition of function `g'
|
| zonkIdOcc: g_aoQ
|
| panic! (the `impossible' happened):
| lookupBindC:no info!
| for: g_aoQ
| (probably: data dependencies broken by an optimisation pass)
| static binds for:
| Tmp.$d1{-rmM,x-}
| local binds for:
|
| Two seconds later, my system crashed. I assume ghc-2.03 did not cause this :-)
|
|
| Regards,
|
|
| Marc
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 patterns in the definition of function `g'
zonkIdOcc: g_aoQ
panic! (the `impossible' happened):
lookupBindC:no info!
for: g_aoQ
(probably: data dependencies broken by an optimisation pass)
static binds for:
Tmp.$d1{-rmM,x-}
local binds for:
Two seconds later, my system crashed. I assume ghc-2.03 did not cause this :-)
Regards,
Marc
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 12:14:47 +0100 (BST) | 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] | k. | Fail: "typecheck/Unify.lhs", line 60: incomplete pattern(s) to match in funct | ion "unifyTauTyLists" | | Caused by the following faulty program: | | module F( f ) where | | f :: (Ord c) = c - c | f c = g c | | g :: c - c | g c = c |where p = foldr (f c) [] [] | | Regards, | | | | Marc
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 following faulty program: module F( f ) where f :: (Ord c) = c - c f c = g c g :: c - c g c = c where p = foldr (f c) [] [] Regards, Marc
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 functional language. The typechecker error recovery was doing a sort of backtracking thing. Simon
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 (Age) Your code is fine, it's GHC that's at fault. You are rightly pushing on newtypes which aren't very throughly tested. I'll fix this asap. We're planning a source release within a fortnight, which will contain the fixes. Simon
[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 = do putStr "a" let x = "b" in putStr x results in: bug7.lhs:7:1: do statements must end with expression on input: EOF Are these expressions correct? (As usual, they work for me in Hugs.) -- Tomasz Cholewo
[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 error messages, including: bug5.lhs:2: Module Main must include a definition for Main.main 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: a = 1 b = 1 c = 1 results in 56 messages. Whole this madness can be cut short by adding any definition for `main', e.g.: main = print 1 -- Tomasz Cholewo
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 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
|
| data X = A {a :: Int}
| y = let A {a} = x
| in a
|
| fails with:
| bug4.lhs:4:5: Not a valid LHS on input: "in"
|
| Rewriting it as an explicit
|
| y = case x of
|A {a} - a
|
| seems to help.
|
| I guess that the support for labeled fields is not quite implemented
| yet? In Hugs the above two examples are working.
|
| -- Tomasz Cholewo
