RE: GHC 6.0 (Sparc-Solaris) bug
This was a grevious bug in 6.0, fixed in 6.0.1. I believe Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Till Mossakowski | Sent: 15 October 2003 17:21 | To: [EMAIL PROTECTED] | Subject: GHC 6.0 (Sparc-Solaris) bug | | Hi, | is this still interesting for you? | (it has been produced with a rather large source tree...) | | Till Mossakowski | | GUI/ConvertDevToAbstractGraph.hs:453: | Warning: Pattern match(es) are overlapped | In a case alternative: otherwise - ... | ghc-6.0: panic! (the `impossible' happened, GHC version 6.0): | coreSyn/CoreUtils.lhs:1188: Non-exhaustive patterns in function isCrossDllArg | | | Please report it as a compiler bug to [EMAIL PROTECTED], | or http://sourceforge.net/projects/ghc/. | | perl utils/create_sources.pl hetcats-make sources_hetcats.mk | Error: Couldn't create sources!! | gmake: *** [sources_hetcats.mk] Error 7 | [EMAIL PROTECTED] - | -- | Till Mossakowski Phone +49-421-218-4683 | Dept. of Computer Science Fax +49-421-218-3054 | University of Bremen [EMAIL PROTECTED] | P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till | | ___ | 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: ghc 6.0.1 win98 System.system too successful?
On Windows, Hugs' implementation of System.system always returns ExitSuccess because the Windows routine it calls doesn't return a useful exit status. Thanks, I hadn't noticed before, but you're right: Hugs suffers from the same bug. My very vague memory from looking into this some years back was that DOS programs don't have a consistently interpreted exit status the way Unix programs do and use some kind of out-of-band communication to indicate failure to the caller. Assuming this is the cause of the bug, shouldn't ghc's/hugs' implementation of System.system on Windows98 make use of this out-of-band communication (which would then seem to be the standard usage pattern on this platform), in order to provide a more useful exit status in our Haskell programs? Cheers, Claus ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
user package blocks standard ones
Please, what is the matter with the packages in ghc-6.0.1 ?
(ghc-6.0.1
installed from RPM on Red Hat Linux release 7.3 (Valhalla),
i-386 unknown
)
It does not find the library items, say List.sort,
when it `makes' under the user package in the user project
importing standard library.
This package is called docon, and it is for a contrived project
of a single small module.
Similarly, ghci -package-conf docon.conf
reports
Loading package docon ... linking ...
/home/mechvel/test/export/HSdocon.o: unknown symbol `__stginit_List_'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
can't load package `docon'
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Either it loads the packages of GHC itself, or, if it deals with
the user package, the packages of GHC are somehow blocked out.
When the user project does not import List and the such, then
ghc --make -package-conf docon.conf
works
but ghci -package-conf docon.conf
still does not (probably, it still needs to load some ghc packages).
The user package is
Package {name= docon,
import_dirs = [$e],
source_dirs = [],
library_dirs= [$e],
hs_libraries= [HSdocon],
extra_libraries = [],
include_dirs= [],
c_includes = [],
package_deps= [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = []
}
, $e is the the path to user package .hi, .o, and library directory.
I struggled with it for two days.
Then, occasionally, tried to set package_deps = [data]
, even though my contrived user package does not use data.
And it started to work, to load everything needed!
Then I try package_deps = [base]
And here ghci -package-conf docon.conf
reports again the `panic'.
Here follows the precise data.
The file Head.hs in the `root' directory $(s) contains
module Head where import List (sort)
f = sort [1,2] :: [Int]
The file Makefile in the same directory is for creating the
package and `making' the project. So that the command
make docon
does the following in succession.
* creates a directory $(e) = $(s)/export
* makes a project by
$(ghc) $(HCFlags) --make Head -package-name docon
* creates the libraries $(e)/libHSdocon.a $(e)/HSdocon.o
with ar and ld
* creates a package docon referring to these libraries:
echo $(pack) | ghc-pkg -f $(s)/docon.conf -u
,
where $(pack) is a string for the package which Makefile sets
earlier.
The command make clear is for un-doing of all this.
Here is the precise Makefile:
ghc = /usr/bin/ghc
# edit these two ***
s = /home/mechvel/test
e = $(s)/export
RANLIB = ar -s
HCFlags = -odir $(e) -hidir $(e)
pack = Package {name= \docon\, \
import_dirs = [\$(e)\],\
source_dirs = [], \
library_dirs= [\$(e)\],\
hs_libraries= [\HSdocon\], \
extra_libraries = [], \
include_dirs= [], \
c_includes = [], \
package_deps= [], \
extra_ghc_opts = [], \
extra_cc_opts = [], \
extra_ld_opts = [] }
obj:
if [ ! -d $(e) ]; then mkdir $(e); fi
$(ghc) $(HCFlags) --make Head -package-name docon
docon: obj
rm -f $(e)/libHSdocon.a $(e)/HSdocon.o
ar -qc $(e)/libHSdocon.a $(wildcard $(e)/*.o)
$(RANLIB) $(e)/libHSdocon.a
ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
ghc-pkg -f $(s)/docon.conf -l
echo $(pack) | ghc-pkg -f $(s)/docon.conf -u
ghc-pkg -f $(s)/docon.conf -l
clear:
ghc-pkg -f $(s)/docon.conf -r docon
rm -f $(s)/docon.conf.old
rm -rf $(e)
rm -f $(s)/log
To exclude the List library, comment out the line `import ..'
and replace the line `f = ...' with `f = True'.
Question on ghc-pkg -g
===
User guide for packages does not explain this precisely.
I suspect that
ghc-pkg -g
may help to replace the messy line
ld -r -x --whole-archive $(e)/libHSdocon.a -o $(e)/HSdocon.o
in the above Makefile, but cannot guess how to use here this
ghc-pkg -g.
Is it clear from the guide paragraph
interactive: internal error: scavenge:
Dear GHC team, ghc-6.0.1 installed from RPM on Red Hat Linux release 7.3 (Valhalla) i-386 unknown runs into the following bug after `making' of my large project and when running the test T_.test log from Interpreter: ... finds gs' = Groebner basis gs, tests the reduction of fs by gs, gs' by gs, gs by gs', tests the transformation matrix fs - gs --- RESULT: [True,interactive: internal error: scavenge: unimplemented/strange closure type 64 @ 0x4056c418 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ The same test compiled to Main.main and --make-ed to a.out runs correct. The project is large, and the bug looks hard to locate. The archive of the source to install is about 900 Kb. I could send it to the GHC team on the subject of debugging GHC, if you tell me any appropriate personal address. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
interactive: internal error: scavenge
addition to the previous bug report on interactive: internal error: scavenge : when the project is made under -O, this bug is not revealed (but it may, for example, appear under different memory options, who knows). ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
interactive: internal error, ghc-6.0.1
I suspect that may previous bug report on interactive interpreter should be replaced with the following one, which is simple to analyse. This is on ghc-6.0.1 installed from RPM on Red Hat Linux release 7.3 (Valhalla), i-386 unknown. Probably, you can reduce the example several times more. ghci Main +RTS -M1m -RTS .. : Main .. main ... (interactive: internal error: thread_stack: weird activation record found on stack: 1564 Please report this as a bug to [EMAIL PROTECTED] .. Probably, the interpreter manages memory in a wrong way. Can you reproduce the effect? Regards, - Serge Mechveliani [EMAIL PROTECTED] --- main = let xs = [1..9000] -- change this number -- and see the message from ghc (x's, s1) = sortE compare xs in putStr $ shows s1 \n type CompValue= Ordering type Comparison a = a - a - CompValue mergeE :: Comparison a - [a] - [a] - ([a],Char) -- Extended merge: -- the transposition sign '+' | '-' is also accumulated. mergeE cp xs ys = m xs ys $ evenL xs where m [] ys _ = (ys,'+') m xs [] _ = (xs,'+') m (x:xs) (y:ys) ev = case cp x y of GT - (y:zs, mulSign s ev) where (zs,s) = m (x:xs) ys ev _ - (x:zs, s) where (zs,s) = m xs (y:ys) (invSign ev) ortE :: Comparison a - [a] - ([a],Char) -- Extended sort: -- the permutation sign '+' | '-' also accumulates. sortE _ [] = ([] , '+') sortE _ [x] = ([x], '+') sortE cp xs = let (ys ,zs) = halve xs (ys',s1) = sortE cp ys (zs',s2) = sortE cp zs (us ,s3) = mergeE cp ys' zs' in (us, mulSign s3 $ mulSign s1 s2) halve :: [a] - ([a],[a]) halvexs = h [] xs xs where h ls (x:rs) (_:_:ys) = h (x:ls) rs ys h ls rs _= (reverse ls, rs) mulSign :: Char - Char - Char mulSignx y= if x==y then '+' else '-' invSign :: Char - Char invSign'+' = '-' invSign'-' = '+' evenL :: [a] - Char evenL [] = '+' evenL (_:xs) = invSign $ evenL xs --- ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: user package blocks standard ones
Serge D. Mechveliani wrote: [...] /home/mechvel/test/export/HSdocon.o: unknown symbol `__stginit_List_' [...] Then, occasionally, tried to set package_deps = [data] , even though my contrived user package does not use data. And it started to work, to load everything needed! Then I try package_deps = [base] And here ghci -package-conf docon.conf reports again the `panic'. [...] I don't have your sources at hand, but it looks like they depend on the haskell98 package. Package data depends on haskell98, BTW. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Wildly inaccurate profiling results
[Sorry if this shows up twice -- I accidentally posted from the wrong address and left something out.] I have a program, compiled with cost-center profiling on, that takes about 5 minutes, 30 seconds to run (measured with a stopwatch), but the resulting .prof file reports the total time as 34 seconds. I know that this number doesn't include overhead due to profiling, but surely the overhead can't be that much! (Also, the program runs about as long when run without -P.) I'm using a copy of GHC built from sources checked out around July 1. Also, using top I've observed that the program takes up about 120MB of memory, and I have much more memory than that, so there's no swapping going on. I'd include the program, but it's very large and I'm not sure how to minimize it and preserve the same behavior. Any ideas as to what the problem might be? Thanks, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt I always feel I have to take a stand, and there's always someone on hand to hate me for standing there / I always feel I have to open my mouth, and every time I do, I offend someone somewhere...--Ani DiFranco http://www.cs.berkeley.edu/~krc/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
