Re: runghc printing result of main when main is not IO ()
tomasz.zielonka: On Thu, Aug 30, 2007 at 08:33:37AM +0100, Simon Marlow wrote: Tomasz Zielonka wrote: Hello! Consider: $ cat R.hs main = return [()] $ runghc R.hs [()] This was a bit surprising for me, because I thought that runghc mimics the way a compiled program behaves. This doesn't happen with 6.6.1, I believe we fixed it at some point by having runghc perform main return () instead of just main. Great! I'm sorry for not checking with a recent version :-/ It was a cute feature though -- great for demos where you can avoid a print statement ;) -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.HashTable.hashInt seems somewhat sub-optimal
Simon.Frankau: I tried submitting this bug through the tracker, but it seemed to give me permissions errors - probably a firewall issue here. :( Apologies. Just a note that HashTable is pretty redundant in Haskell. For sizes you can fit in memory, Map, IntMap or Data.Sequence perform at effectively O(1) for reasonable purposes, and can hold larger numbers of elements than Data.HashTable. -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHCi and Windows 98
steven-tinsley: Good day to you. I installed GHC 6.6 on a Windows 98 SE system recently having decided to try to learn this language. Unfortunetley, GHCi causes an This program has performed an illegal operation error at startup and is shut down. This happens just after Loading base packagelinkingdone is shown. Windows produces this error message: [code] GHC caused an invalid page fault in module GHC.EXE at 0167:00c82e26. Registers: EAX=0078 CS=0167 EIP=00c82e26 EFLGS=00010297 EBX=00d963c8 SS=016f ESP=010cdd50 EBP=01c43f3c ECX=0007 DS=016f ESI=01be57e8 FS=1617 EDX= ES=016f EDI=01be57f4 GS= Bytes at CS:EIP: 66 83 3c 50 00 74 19 ff 45 00 83 ef 08 b8 18 2e Stack dump: 0078 0200 0001 00d0fe5c 0002 00cddbb6 0001 00c34b9c 00408442 [/code] Just thought you'd like to know. Thanks. Steven. Thanks, this is fixed, I think: http://hackage.haskell.org/trac/ghc/ticket/976 http://hackage.haskell.org/trac/ghc/ticket/970 is that the same problem? -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #887: GHCi prints results of IO actions
trac: #887: GHCi prints results of IO actions --+- Reporter: guest| Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi |Version: 6.5 Severity: normal | Resolution: Keywords: | Os: Linux Difficulty: Unknown | Architecture: x86 --+- Comment (by simonpj): We changed it because a lot of the time it's very convenenient to see the result of an action. But you have a good point. (As an unsatisfactory workaround, you could wrap x an un-Showable constructor, or in a function; but that changes its type.) What do others think? Return to old behaviour? Have another settable option? Or what? I was thinking about this a bit. Ideally we'd have: :set verbose :unset verbose or similarly, to switch between the two behaviours. -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.2 and 6.4.1 on IRIX64 both failed, this time with new error
simonmarhaskell: -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o Cmm lint error: in proc stg_ap_0_ret in basic block c2 in assignment: R1 = I32[R1 + 8 + 0]; This looks like an inconsistency in bit widths somewhere: GHC thinks the width of a word is 64, but soemthing else thinks its 32 bits. I suspect ghc/includes/DerivedConstants.h doesn't agree with ghc/includes/ghcautoconf.h. Perhaps you're not passing -mabi when compiling ghc/includes/mkDerivedConstants.h? Yes, when hacking on irix/mips64, I needed: export LDFLAGS=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib -mabi=64 export CPPFLAGS=-I/usr/freeware/include -I/import/pill0/1/dons/include export CFLAGS=-mabi=64 export GHCRTS=-K20m export LD=/usr/bin/ld -64 cat mk/build.mk END SRC_CC_OPTS+=-mabi=64 SRC_HC_OPTS+=-optc-mabi=64 -opta-mabi=64 -optl-mabi=64 SRC_CC_OPTS+=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib SRC_HC_OPTS+=-L/usr/freeware/lib64 -L/import/pill0/1/dons/lib END And you'll need to add them to the final compiler's package.conf ldOptions as well. Btw, Andrew, did you try the ghc 6.0.1 Irix/mips64 binary on haskell.org/ghc? -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc needing ghc is the biggest bug in ghc
dh: Are you fully nerd How can ghc expect an installed ghc for the first build stage? What is that I know! What is wrong with all these functional programmers defining everything with recursion I think they do it just to be fully nerd!!! ;) -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: repeatable instance of impossible error
simonmar: Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. plugins depends on Cabal, doesn't it? I suspect that Cabal-1.0 is your missing package. Ah ha! Of course, silly me. Rebuilding plugins with the new cabal fixes the panic when building yi. -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: the impossible happened
bulatz: also it will be cool to have ability to add such annotations to my own functions, smthg like: head (x:xs) = x head [] = superError head [] which will print: Error: head [] in Module.hs:155 You can do this already with GHC.Base.assert (almost): import GHC.Base (assert) f [] = assert False () f x = () *Main f [1,2] () *Main f [] *** Exception: t.hs:3:7-12: Assertion failed At least you can get the line number. -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: loop performance bug
duncan.coutts: This sort of code runs very slowly when compared to the equivalent in C: This example uses unboxing and primops over Lemmih's and seems to run a bit faster: Lemmih's loops: ./a.out 1.35s user 0.00s system 99% cpu 1.359 total This code: ./a.out 0.99s user 0.00s system 98% cpu 1.008 total C: ./a.out 0.14s user 0.00s system 101% cpu 0.138 total import GHC.Base import GHC.IOBase import GHC.Prim import GHC.Pack data M = M (MutableByteArray# RealWorld) main = do (M a) - IO $ \s - case newByteArray# (4#*#100#*#100#) s of (# s',ar #) - (# s',M ar #) doFromTo 0 $ \_ - doFromTo 0 99 $ \y - doFromTo 0 99 $ \x - do IO $ \s - case writeIntArray# (unsafeCoerce# a) (x *# (y +# 1#)) s of s' - (# s', () #) doFromTo (I# from) (I# to) action = do let loop n | n # to = return () | otherwise = action n loop (n+#1#) loop from Changing the index calculation (x *# (y +# 1#) to a constant halves the runtime, again, though that may not be very useful information ;) -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Illtyped generated code with unsafeCoerce#, F# and -O
Hey guys, The following (evil, yes) program compiles and works under ghc -Onot using -fasm or -fvia-C, but fails to generated correct code under all GHCs back to ghc-5.04.2 if I turn on -O. (It also works under ghci). When working it runs and produces the following (correct) result: paprika$ ./a.out .0 (69,243,8,0) .0 However, if I turn on -O it fails to generate acceptable asm or C. Am I right in thinking that all uses of unsafeCoerce# should never cause type-incorrect C or asm code to be generated (no matter what evil happens at runtime)? Now, -dcore-lint is fine, but our shiny new 6.4 -dcmm-lint spots the error :) Cmm lint error: in proc s2D4_ret in basic block c2F7 in MachOp application: .0 :: F32 255 Here's the result -O -fvia-C: paprika$ ghc-6.4 -no-recomp -fglasgow-exts -O -fvia-C t.hs /tmp/ghc5870.hc: In function `s2D4_ret': /tmp/ghc5870.hc:253: error: invalid operands to binary /tmp/ghc5870.hc: In function `Main_lvl2_entry': /tmp/ghc5870.hc:412: error: invalid operands to binary where relevant lines are: 253: _s2D8 = ((StgFloat).0) 0xff; and 472: _s2Dg = ((StgFloat).0) 0xff; There appears to be a missing (W_) cast (?). And -O -fasm: paprika$ ghc-6.4 -no-recomp -fglasgow-exts -O -fasm t.hs /tmp/ghc7685.s: Assembler messages: /tmp/ghc7685.s:309: Error: bad register name `%st(-7)' /tmp/ghc7685.s:316: Error: bad register name `%fake0' /tmp/ghc7685.s:317: Error: bad register name `%fake0' /tmp/ghc7685.s:472: Error: bad register name `%st(-7)' the relevant lines are: 309: ffree %st(7) ; flds .Ln2GX ; fstp %st(-7) 316: movl 8(%ebp),%fake0 317: orl %eax,%fake0 472: ffree %st(7) ; flds .Ln2HH ; fstp %st(-7) We get a similar result with ghc-6.2.2 (but of course don't have a -dcore-lint pass to spot the type error ;) paprika$ ghc-6.2.2 -no-recomp -keep-tmp-files -fglasgow-exts -O -fasm t.hs /tmp/ghc4107.s: Assembler messages: /tmp/ghc4107.s:278: Error: bad register name `%st(-7)' /tmp/ghc4107.s:675: Error: bad register name `%fake0' /tmp/ghc4107.s:676: Error: bad register name `%fake0' paprika$ ghc-6.2.2 -no-recomp -keep-tmp-files -fglasgow-exts -O -fvia-C t.hs /tmp/ghc7876.hc: In function `Main_zdwg_entry': /tmp/ghc7876.hc:221: error: invalid operands to binary And even back to ghc-5.04.2: zywiec$ ghc-5.04.2 -O -fglasgow-exts -fvia-C t.hs /tmp/ghc2973.hc: In function `Main_a_entry': /tmp/ghc2973.hc:27: invalid operands to binary zywiec$ ghc-5.04.2 -O -fglasgow-exts -fasm t.hs /tmp/ghc2977.s: Assembler messages: /tmp/ghc2977.s:79: Error: bad register name `%st(-7)' /tmp/ghc2977.s:774: Error: bad register name `%fake0' /tmp/ghc2977.s:775: Error: bad register name `%fake0' /tmp/ghc2977.s:776: Error: bad register name `%fake0' /tmp/ghc2977.s:777: Error: bad register name `%fake0' -- Don And here's the nefarious code: import GHC.Word import GHC.Float import GHC.Base import Data.Bits main = let f = .0 f' = g f f''= g' f' in do putStrLn (show f) putStrLn (show f') putStrLn (show f'') g :: Float - (Word8,Word8,Word8,Word8) g (F# f) = let w = W32# (unsafeCoerce# f) w0= fromIntegral (w `shiftR` 24) w1= fromIntegral ((w `shiftR` 16) .. 0xff) w2= fromIntegral ((w `shiftR` 8) .. 0xff) w3= fromIntegral (w .. 0xff) in (w0,w1,w2,w3) g' :: (Word8,Word8,Word8,Word8) - Float g' (w0,w1,w2,w3) = let (W32# w) = (fromIntegral w0 `shiftL` 24) .|. (fromIntegral w1 `shiftL` 16) .|. (fromIntegral w2 `shiftL` 8) .|. (fromIntegral w3) in F# (unsafeCoerce# w) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Illtyped generated code with unsafeCoerce#, F# and -O
wolfgang.thaller:
g (F# f) =
let w = W32# (unsafeCoerce# f)
Why does GHC even accept this code?
I think unsafeCoerce# is not intended to be able to coerce unboxed
values.
Prelude GHC.Base :t unsafeCoerce#
unsafeCoerce# :: forall b a. a - b
The type variables a and b are supposed to be of kind *, and f is of
kind #.
How do you know the tyvars have kind * ? Anyway, it's even used like
this in the libraries :)
GHC.Conc:
mkWeak key val Nothing = IO $ \s -
case mkWeak# key val (unsafeCoerce# 0#) s of
{ (# s1, w #) - (# s1, Weak w #) }
So those tyvars must really be ? kind (I think). I.e.
forall b:? a:? . a - b
or
forall b:?? a:?? . a - b
There's a description of this stuff in types/Kind.lhs.
Also, I see in basicTypes/MkId.lhs:
unsafeCoerce# isn't so much a PrimOp as a phantom identifier, that
just gets expanded into a type coercion wherever it occurs. Hence we
add it as a built-in Id with an unfolding here.
The type variables we use here are open type variables: this means
they can unify with both unlifted and lifted types. Hence we provide
another gun with which to shoot yourself in the foot.
open == ??, I think, and the above comment explains the unsafeCoerce# behaviour
I'm using/shooting myself with. Further down:
ty = mkForAllTys [openAlphaTyVar,openBetaTyVar]
(mkFunTy openAlphaTy openBetaTy)
which looks like: a:?? - b:?? to me. In prelude/TysPrim.lhs:
-- openAlphaTyVar is prepared to be instantiated
-- to a lifted or unlifted type variable. It's used for the
-- result type for error, so that we can have (error Int# Help)
openAlphaTy = mkTyVarTy openAlphaTyVar
So I think this all implies that unsafeCoerce# x# is legal, though not polite.
Cheers,
Don
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.2.2: unknown package name: Main (again)
gwright: Hi, Using ghc-6.2.2 on Mac OS X 10.3.6, I've found another instance of the unknown package name: Main problem mentioned last April. When I build my program I see: crossroads-able ghc --make -package hsshellscript -o asgraph asgraph.hs Chasing modules from: asgraph.hs Skipping Reformat ( ./Reformat.hs, ./Reformat.o ) Skipping Main ( asgraph.hs, asgraph.o ) Linking ... ghc-6.2.2: unknown package name: Main However, building the package (hsshellscript) with the additional option -package-name hsshellscript doesn't fix the problem; the error message persists. Has anyone else noticed this probelm? Is it specific to OS X? I had this problem in yi at one point, when trying to link against a package, in the same directory as the package .o files. Check the resulting .hi files (--show-iface) to see if you linked against the -package hsshellscript, or the individual .o files. The .o files were getting picked up by -I., overriding the -package flag. The solution was to use either -I to explicitly rule out certain dirs from the search path. Another soln (that is backwards compatible with ghc-6.2.1) is to cd to another dir, so that the -I. doesn't mean anything. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC page
mechvel: Dear GHC team, I needed to download ghc-6.2.2. My (old) brouser takes www.haskell.org but is not able to get the picture of www.haskell.org/ghc , just gets aborted. Several months ago this page became readable, and now again changed. Please, how to reach GHC in a regular way (www or anonymous ftp) ? http://www.haskell.org/ghc/dist/6.2.2/ -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
data T = () crash
This program causes HEAD from 15 May to crash: data T = () main = undefined paprika$ ghc t.hs ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): ASSERT failed! file rename/RnEnv.lhs, line 79 Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. The code was generated by an incorrect sed pass over a source file :} -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: compiling PrimOp.lhs
mechvel: Dear GHC developers, `Making' GHC of cvs update -r ghc-6-2-branch with ghc-6.2.1 on RedHat Linux (about version 8) libc-2.2, i686 seems to meet a problem: ** ... myfptools ... ... cd myfptools ./configure --prefix=... ... make boot ... run it from ghc or ... -- OK, probably make boot not needed, right? make all make[1]: Entering directory `/disk2/home/mechvel/ghcCVS/myfptools/glafp-utils' --- ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest docbook lndir ... PWD = /disk2/home/mechvel/ghcCVS/myfptools/glafp-utils ... ... e1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis ... -c basicTypes/NewDemand.lhs -o stage1/basicTypes/NewDemand.o -ohi stage1/basicTypes/NewDemand.hi ghc: 159979968 bytes, 32 GCs, 3950581/8666736 avg/max bytes residency (4 samples), 20M in use, 0.01 INIT (0.00 elapsed), 1.09 MUT (3.03 elapsed), 0.50 GC (0.55 elapsed) :ghc /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes ... fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-recomp -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi ./primop-tag.hs-incl:2: Warning: Pattern match(es) are overlapped In the definition of `tagOf_PrimOp': tagOf_PrimOp op = ... *** Now, it stayed at this point for about 50 minutes, no messages appear, ghc-6.2.1, cc1 keep on being re-envoked in turn. I have just interrupted it. This module does not look large, and is given -H80m ... What is the matter, please? Do you have a very slow machine? Very low memory? It takes maybe 15-20 minutes to compiler PrimOp.lhs on a 150 MHz SPARCstation-20. Probably not the machine, though. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: charToUtf8 1883885648 panic on sparc
simonmar: On 26 April 2004 17:52, Ian Lynagh wrote: On sparc, GHC is failing when building hmake as below: - /usr/bin/haskell-compiler-package lang -c -o /build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/QSort.o QSort.hs /usr/bin/haskell-compiler-package lang -c -o /build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/Unlit.o Unlit.hs ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): charToUtf8 1883885648 Does this only happen on Sparc? I don't have a sparc box handy to debug on. Can I have an account on yours? :-) hmake-3.08 builds fine under ghc-6.2.1 on sparc/openbsd, for what it is worth. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: charToUtf8 1883885648 panic on sparc
dons: simonmar: On 26 April 2004 17:52, Ian Lynagh wrote: On sparc, GHC is failing when building hmake as below: - /usr/bin/haskell-compiler-package lang -c -o /build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/QSort.o QSort.hs /usr/bin/haskell-compiler-package lang -c -o /build/buildd/hmake-3.08/targets/sparc-Linux/obj/hmake/Unlit.o Unlit.hs ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): charToUtf8 1883885648 Does this only happen on Sparc? I don't have a sparc box handy to debug on. Can I have an account on yours? :-) hmake-3.08 builds fine under ghc-6.2.1 on sparc/openbsd, for what it is worth. Hmm. That build is dying very early in.. === Building for hmake-3.08 cd src/hmake; gmake HC=ghc install config gmake[1]: Entering directory `/usr/obj/ports/hmake-3.08/hmake-3.08/src/hmake' mkdir -p /usr/obj/ports/hmake-3.08/hmake-3.08/targets/sparc-OpenBSD/obj/hmake || /usr/bin/true ghc-package lang -c -o /usr/obj/ports/hmake-3.08/hmake-3.08/targets/sparc-OpenBSD/obj/hmake/QSort.o QSort.hs ghc-package lang -c -o /usr/obj/ports/hmake-3.08/hmake-3.08/targets/sparc-OpenBSD/obj/hmake/Unlit.o Unlit.hs ... The second file to be built. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci and unboxed ints
simonpj: I don't honestly know! I could probably find out but it'd take a bit of poking | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Josef Svenningsson | Sent: 06 May 2004 14:16 | To: Simon Peyton-Jones; 'Donald Bruce Stewart' | Cc: [EMAIL PROTECTED] | Subject: RE: ghci and unboxed ints | | Just out of curiosity. The number that is displayed, what does it mean? My | first thought was that it was the address to the allocated thunk. But then | since everything got the same number that doesn't seem right. | | Anyway, it was a fun bug :-) | | /Josef | | -Original Message- | From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED] | Sent: den 6 maj 2004 13:31 | To: Donald Bruce Stewart; Josef Svenningsson | Cc: [EMAIL PROTECTED] | Subject: RE: ghci and unboxed ints | | Fixed now! Thanks for pointing it out. The story is that you can | only bind lifted (boxed) things. Ah, of course. I was a bit confused, as: main = putStrLn (show ( let a = 1# in I# a )) does bind, and compile. But I guess that's because it isn't at the top level? -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci and unboxed ints
josefs: Hi, I just played randomly with ghci for a while and encountered the following rather odd behaviour: Prelude :m GHC.Base Prelude GHC.Base let a = 1# +# 2# Prelude GHC.Base show (I# a) 18345984 The number shown is the one I got when running on Solaris. I get a different one when running on Windows. It doesn't matter which numbers I add, the same number is always shown. Reproducible with 6.2 and 6.2.1. I don't know what the issue is, but it is interesting: Prelude :m GHC.Base Prelude GHC.Base case 1# +# 2# of a - show (I# a) 3 Prelude GHC.Base let a = 1# +# 2# Prelude GHC.Base show (I# a) 1085417808 $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.3.20040202 -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci and unboxed ints
dons: josefs: Hi, I just played randomly with ghci for a while and encountered the following rather odd behaviour: Prelude :m GHC.Base Prelude GHC.Base let a = 1# +# 2# Prelude GHC.Base show (I# a) 18345984 The number shown is the one I got when running on Solaris. I get a different one when running on Windows. It doesn't matter which numbers I add, the same number is always shown. Reproducible with 6.2 and 6.2.1. I don't know what the issue is, but it is interesting: Prelude :m GHC.Base Prelude GHC.Base case 1# +# 2# of a - show (I# a) 3 Prelude GHC.Base let a = 1# +# 2# Prelude GHC.Base show (I# a) 1085417808 $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.3.20040202 And, just for fun (since I don't know enough ghci to help): $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.2 $ uname -msr Linux 2.6.0-test9 ia64 Loading package base ... linking ... done. Prelude :m GHC.Base Prelude GHC.Base case 1# +# 2# of a - show (I# a) 3 Prelude GHC.Base let a = 1# +# 2# Prelude GHC.Base show (I# a) zsh: segmentation fault ghci -fglasgow-exts -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug in GHC 6.2.1
./a.out[21:57] # Now hit Ctrl-C a.out: internal error: main thread has been GC'd Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ Thanks, that's a bug. I've fixed it in CVS. As far as I can tell, only aborting a program with Ctrl-C should trigger the bug. Same issue OpenBSD x86 when you hit Ctrl-C. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.2 possible bug with gcc 3.3.x, strange parse error
bjpop: Hi, Something very mysterious is happening when buddha is built with GHC 6.2 on machines that have gcc 3.3.x This bug has occurred on these two machines so far: Gentoo linux with gcc 3.3.2 FreeBSD with gcc 3.3.3 Both x86 machines. Note however, that the bug does not appear on machines with gcc 2.x series compilers. buddha can be downloaded from: www.cs.mu.oz.au/~bjpop/buddha The file in question is (from the buddha soure package): prelude/Buddha/List_B.hs GHC gives a parse error on this line of code: infix 5 \\ The error message is: List_B.hs:23: parse error on input `\' I don't think there is any parse error in the file, and GHC 6.2 with gcc 2.x doesn't think so either. I'm pretty sure SimonM mentioned something on the list a few months ago about gcc3-cpp changing the way it processes the end of \ line style tokens. It would be in the archives, and maybe in the user's guide (there's something about string gaps in there, at least). Cheers, Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Missing table for -opt? flags in users_guide:phases.sgml
Hey, In users_guide/phases.sgml, in the section concerning passing flags through to cc, as or ld, I think there is a missing list of flags: sect2 id=forcing-options-through titleForcing options to a particular phase/title indextermprimaryforcing GHC-phase options/primary/indexterm paraOptions can be forced through to a particlar compilation phase, using the following flags:/para ^^ paraSo, for example, to force an option-Ewurble/option option to the assembler, you would tell the driver option-opta-Ewurble/option (the dash before the E is required)./para The underlined section is where, I think, -optc, -opta, and -optl should be listed. This is missing in the 6.0.1 guide, and the current cvs guide, although I am not 100% certain what you want to put here. -- Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: LD_LIBRARY_PATH, ghc and Solaris
ger: It looks like I am going to have to hack the shell script that calls ghc, because it needs to set LD_LIBRARY_PATH so that the executables can find libreadline. Would it be possible to have an option to ./configure that set a library path to be used by these scripts? I have to do a similar thing on OpenBSD, to use an external libgmp residing in /usr/local/lib. But no real hacking is required! When compiling GHC, before you start, add something like: , -L, /usr/local/lib to somewhere down around line 137 of ghc/rts/package.conf.in. This way GHC will always add the -L/usr/local/lib flag when compiling .hs files and will find whatever library you need. -- Don Here is a patch I use: --- ghc/rts/package.conf.in.origSat May 17 10:11:27 2003 +++ ghc/rts/package.conf.in Wed Aug 6 15:12:45 2003 @@ -133,6 +133,7 @@ , -u, GHCziWeak_runFinalizzerBatch_closure , -u, __stginit_Prelude #endif + , -L, /usr/local/lib ] #ifdef HAVE_FRAMEWORK_HASKELLSUPPORT , extra_frameworks = [ HaskellSupport ] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
assert failed in head build
Last nights (Sep 13 EST) build of cvs HEAD on i386-unknown-openbsd
died in the stage3 build with the following output:
-- Don
/home/dons/ghc/cvs/nightly/i386-unknown-openbsd/stage2/ghc/compiler/ghc-inplace
-H16m -O -fvia-C -keep-hc-file -istage1/utils -istage1/basicTypes -istage1/
types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck
- istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore
-is tage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen
-istage1/a bsCSyn -istage1/main -istage1/profiling -istage1/parser
-istage1/cprAnalysi s -istage1/compMan -istage1/ndpFlatten -istage1/cbits
-istage1/nativeGen - istage1/ghci -DGHCI -package haskell-src -package unix
-package readline -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen
-Iparser -recomp -O -dcor e-lint -H24m -fvia-C -keep-hc-file -H16M '-#include
hschooks.h'-c simplC ore/Simplify.lhs -o stage1/simplCore/Simplify.o
-ohi stage1/simplCore/Simplify .hi
ghc-6.3: panic! (the `impossible' happened, GHC version 6.3):
ASSERT failed! file simplCore/Simplify.lhs line 548
[lvl_sgIH S :: GHCziBase.Bool {- tc 3c -}
Str: DmdType
lvl_sgIH = CoreUtils.exprIsDupable {- v r1lq -}
@ CoreSyn.CoreBndr {- tc r1QO -} mzuresult {- v a4LH -}]
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
ghc: 465015772 bytes, 412 GCs, 6196763/12742672 avg/max bytes residency (7
sa mples), 33M in use, 0.00 INIT (0.00 elapsed), 2.48 MUT (2.63 elapsed), 1.30
GC (1.33 elapsed) :ghc
gmake[1]: *** [stage1/simplCore/Simplify.o] Error 1
gmake: *** [all] Error 1
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Odd GHCi behavior
ketil: Andy Moran [EMAIL PROTECTED] writes: Skipping Util.List( ../../libraries/Util/List.hs, ../../libraries/Util/List.o ) ... Failed to load interface for `Util.List': Doing a big old clean, --make, and then GHCi solved the problem. But what could cause this kind of behavior? (I can't reproduce it, sorry.) Something similar has occasionally happened to me when I've interrupted (^C) a build. Presumably, the compiler gets around to touching the relevant file(s), but stops before it is able to finish them, and doesn't clean up. I've seen this occasionally on private nightly builds over an NFS link. Only over NFS. But this hasn't happened since 6.0.1. It would happen one night, and not the next, even if nothing changed in the source. So I always presumed it was a weird timestamp issue. Now, looking in my old build logs... aaha! I found it! It only ever happened in nofib builds. Here is an example: ==nofib== infer: time to compile InferMonad follows... /home/pls/src/ghc6+stix/nightly/i386-unknown-linux/ghc/compiler/stage3/ghc-inplace -H16m -O -O -funbox-strict-fields -fexcess-precision -Rghc-timing -H32m -hisuf hi -cpp -c InferMonad.hs -o InferMonad.o InferMonad.hs:6: Failed to load interface for `StateX': Could not find interface file for `StateX' (use -v to see a list of the files searched for) InferMonad.hs:6: Module `StateX' does not export `StateX' InferMonad.hs:6: Module `StateX' does not export `returnSX' InferMonad.hs:6: Module `StateX' does not export `eachSX' InferMonad.hs:6: Module `StateX' does not export `thenSX' InferMonad.hs:6: Module `StateX' does not export `toSX' InferMonad.hs:6: Module `StateX' does not export `putSX' InferMonad.hs:6: Module `StateX' does not export `getSX' InferMonad.hs:6: Module `StateX' does not export `useSX' InferMonad.hs:8: Failed to load interface for `Substitution': Could not find interface file for `Substitution' (use -v to see a list of the files searched for) Etc., etc. If someone finds this useful, the entire nightly build logs from that night are available online at: ftp.cse.unsw.edu.au/pub/users/dons/ghc+stix/logs/ Particularly, i386-unknown-linux-nofib-5, which showed this behaviour, although it has occured in other places. Cheers, Don ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
make variable not set in nightly script
Hey, The $MAKE variable is not used in the new_bootstrap stage 2 and 3 parts of the nightly_wrk script. This causes failures at the start of stage2 on OpenBSD (and presumably other non-gnu systems) -- Don P.S. I would commit it myself, but I don't have a tree on this machine. Here is a patch: Index: nightly/bin/nightly-wrk === RCS file: /cvs/nightly/bin/nightly-wrk,v retrieving revision 1.37 diff -u -r1.37 nightly-wrk --- nightly/bin/nightly-wrk 16 Jul 2003 15:18:15 - 1.37 +++ nightly/bin/nightly-wrk 17 Jul 2003 09:40:22 - @@ -354,8 +354,8 @@ $ECHO -n Building stage 2 compiler... if [ $new_bootstrap = YES ]; then (cd $STAGE1_DIR/ghc/compiler \ -time make boot stage=2 \ -time make all stage=2) \ +time $MAKE boot stage=2 \ +time $MAKE all stage=2)\ $LOG_DIR/$arch-stage2 21\ stage2_build_ok=YES; else @@ -397,8 +397,8 @@ if [ $new_bootstrap = YES ]; then (cd $STAGE1_DIR/ghc/compiler \ -time make boot stage=3 \ -time make all stage=3) \ +time $MAKE boot stage=3 \ +time $MAKE all stage=3)\ $LOG_DIR/$arch-stage3 21\ stage3_build_ok=YES; else ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
nightly build nofib failures
Hey, There is a bug in the nightly build scripts for running the nofib suite. Nofib programs can fail, yet the build output will still be ok.. In fact, every single nofib program can fail to compile, but it will still be ok. in the nightly mail. In a normal nightly build, we get this kind of output for a nofib run: running nofib... ok. Taking http://www.haskell.org/pipermail/cvs-ghc/2003-July/017999.html as an example, we see that all nofib's were ok. Now, if we go and look at the logs: http://haskell.cs.yale.edu/ghc/dist/current/logs/ Looking in nofib-2, we see that there are lots (all?) fails: primes, queens, etc. Looking in nofib-5 all tests fail, because it is build the -unreg way witout library support. So here is a quick sh patch against nightly/bin/nightly-wrk to print the number of failures a nofib run produced. It produces output like this, where failures are printed if they occur. running nofib... ok. running nofib... ok. running nofib... ok. (4 failures) running nofib... ok. (4 failures) Cheers, Don Stewart --- Index: nightly/bin/nightly-wrk === RCS file: /cvs/nightly/bin/nightly-wrk,v retrieving revision 1.36 diff -u -r1.36 nightly-wrk --- nightly/bin/nightly-wrk 30 May 2003 01:44:40 - 1.36 +++ nightly/bin/nightly-wrk 14 Jul 2003 01:09:46 - @@ -713,7 +713,18 @@ $nofib_1_opts \ $nofib_1_categories \ '' $LOG_DIR/$arch-nofib-1 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-1 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi @@ -727,7 +738,18 @@ $nofib_2_opts \ $nofib_2_categories \ '' $LOG_DIR/$arch-nofib-2 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-2 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi @@ -741,7 +763,18 @@ $nofib_3_opts \ $nofib_3_categories \ '' $LOG_DIR/$arch-nofib-3 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-3 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi @@ -755,7 +788,18 @@ $nofib_4_opts \ $nofib_4_categories \ '' $LOG_DIR/$arch-nofib-4 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-4 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi @@ -769,7 +813,18 @@ $nofib_5_opts \ $nofib_5_categories \ '' $LOG_DIR/$arch-nofib-5 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-5 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi @@ -783,7 +838,18 @@ $nofib_6_opts \ $nofib_6_categories \ '' $LOG_DIR/$arch-nofib-6 21; then - $ECHO ok. + +F=$LOG_DIR/$arch-nofib-6 +E='not remade because of errors' +FAIL=`grep $E $F | wc -l | sed 's/^ *//'` + +$ECHO -n ok. +if [ $FAIL != 0 ] ; then +$ECHO ($FAIL failures) +else +$ECHO +fi + else $ECHO failed. fi ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
