September 2001 - Nhc-bugs

Segfaults
by Ian Lynagh 30 Sep '01

30 Sep '01

Hi I'm not sure how to simplify this to a simple test case so I've put a complete tarball at http://c93.keble.ox.ac.uk/~ian/igl-0.0.4.tar.gz $ rm -f *.o *.hi Project $ HFLAGS="+RTS -K11048576 -RTS -nkpat" hmake -nhc98 Project nhc98 +RTS -K11048576 -RTS -nkpat -c -o Tokens.o Tokens.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o PCbase.o PCbase.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o PC.o PC.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Parser.o Parser.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Mangle.o Mangle.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o IA.o IA.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Offside.o Offside.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Scanner.o Scanner.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Delit.o Delit.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Args.o Args.lhs nhc98 +RTS -K11048576 -RTS -nkpat -c -o Project.o Project.lhs nhc98 +RTS -K11048576 -RTS -nkpat -o Project PCbase.o IA.o PC.o Parser.o Mangle.o Offside.o Scanner.o Tokens.o Delit.o Args.o Project.o $ cat simple.hs foo = bar $ ./Project < simple.hs Segmentation fault (core dumped) $ Thanks Ian

1 0

nhc installing problems
by Gyun Woo 28 Sep '01

28 Sep '01

Hi, there! On my first trial of installing nhc98 1.08 from sources in my linux machine, I got the following message: > make cd src/compiler98; make fromC make[1]: Entering directory `/home/woogyun/Ftp/nhc98-1.08/src/compiler98' /home/woogyun/Ftp/nhc98-1.08/script//nhc98 -c -d /home/woogyun/Ftp/nhc98-1.08/targets/ix86-Linux/obj/compiler98 *.hc cd /home/woogyun/Ftp/nhc98-1.08/targets/ix86-Linux/obj/compiler98; /home/woogyun/Ftp/nhc98-1.08/script//nhc98 -H8M -o /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp *.o /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(Show_IOError.o)(.data+0x1d4): undefined reference to `CF_Prelude_46Show_46DErrNo_46ErrNo' /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(StrError.o)(.data+0x4c): undefined reference to `FN_Prelude_46Enum_46DErrNo_46ErrNo_46fromEnum' /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/Prelude.a(CError.o)(.data+0x38): undefined reference to `FN_Prelude_46Enum_46DErrNo_46ErrNo_46toEnum' collect2: ld returned 1 exit status strip /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp strip: /home/woogyun/Ftp/nhc98-1.08/lib/ix86-Linux/nhc98comp: No such file or directory make[1]: *** [fromC] Error 1 make[1]: Leaving directory `/home/woogyun/Ftp/nhc98-1.08/src/compiler98' make: *** [targets/ix86-Linux/compiler-gcc] 오류 2 The OS configuration is: > uname -a Linux zen 2.2.17-8wl2 #1 Sun Jan 14 22:01:31 KST 2001 i686 unknown Could you help me? Thanks in advance! - Gyun Woo

2 1

Qualified imports
by Ralf Hinze 27 Sep '01

27 Sep '01

In a larger project I use qualified imports a lot. Now, when I try to compile the program with nhc98 I get ... ... nhc98 -98 -I/home/ralf/Haskell/LibRH/nhc98/ -P/home/ralf/Haskell/LibRH/nhc98/ -c -o Future.o Future.lhs Warning: when renaming newtype of imported newtype: Real type of OrdUniqListFM.FM is not visible. I might get boxed/unboxed info wrong. nhc98 -98 -I/home/ralf/Haskell/LibRH/nhc98/ -P/home/ralf/Haskell/LibRH/nhc98/ -c -o LR0.o LR0.lhs ==================================== Error when renaming:: Identifier unionMany defined 3 times. Identifier fromList defined 3 times. Identifier lookup defined 2 times. Identifier union defined 3 times. Identifier elem defined 2 times. Identifier length defined 3 times. This is basically true. However, the definitions reside in different modules that are imported qualified. Unfortunately, I wasn't able to boil down the error (all the toy programs I came up with work fine). I'll send you the files, if you have time to chase down the bug. Cheers, Ralf

2 1

Type synonyms
by Ralf Hinze 26 Sep '01

26 Sep '01

nhc doesn't like the following program ... > type Option = Maybe > f :: Option a -> Maybe a > f = id > main = putStrLn "hello world" Transscript of the session ... >>> nhc98 --version /home/ralf/Lang/bin/nhc98: v1.08 (2001-09-25) [ config: ix86-Linux/ghc by malcolm(a)pc173.cs.york.ac.uk on 25 Sep 2001 ] >>> nhc98 -v Bug.lhs nhc98comp +RTS -RTS -unlit -P/home/ralf/Lang/include/nhc98 ./Bug.lhs ./Bug.lhs /tmp/Bug.12000.hi /tmp/Bug.12000.hc ==================================== Error after type deriving/checking: Type error can not unify Prelude.Maybe with 1 and 0 arguments when binding final type to function at 4:8. The problem disappears if we change the type definition to > type Option a = Maybe a Cheers, Ralf

2 1

nhc98 module bug
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

The following combination of three modules breaks nhc98 v1.08: ===== First module ====== module M (T, foo) where newtype T = T Int foo :: Int -> T foo x = T (x + 1) ===== Second module ====== module N (foo) where import M (T) import qualified M (foo) data S = S T foo :: Int -> S foo y = S $ M.foo y ===== Third module ====== import N (foo) main = print $ const 42 (foo 100) ========================= Compile with nhc98 -c M.hs nhc98 -c N.hs nhc98 -c Main.hs to get Error when renaming:: Identifier foo defined 2 times. The problem is quite subtle. It is the combination of qualified import of `M.foo' in `N' and export of another `foo' in `N', where `N.foo' has a type that depends on `M.T'. Looking into `N.hi' there are indeed two definitions of `foo', where nhc doesn't seem to properly distinguish that they come from two different modules. Cheers, Manuel PS: In case anybody is wondering, I am still trying to get nhc to compile the basic compiler-support libraries that I need to port C->Haskell.

2 3

hmake stdout/stderr confusion
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

[I hope, this is the right place to report hmake problems.] When hmake emits the message Stop - hmake dependency error. it does so to stdout. I think, it should go to stderr, as the current behaviour in combination with output redirection can be surprising. Cheers, Manuel

2 2

NHC 1.08 & gmp
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

Compiling nhc 1.08 on a RedHat 7.1 machine, I get hmake -nhc98 -K10M +CTS -H20M -CTS Hatobserve /home/chak/sandbox/src/nhc98-1.08/targets/ix86-Linux/obj/hat/hatlib.a -d/home/chak/sandbox/src/nhc98-1.08/lib/ix86-Linux make[1]: hmake: Command not found make[1]: *** [/home/chak/sandbox/src/nhc98-1.08/lib/ix86-Linux/hat-observe] Error 127 make[1]: Leaving directory `/home/chak/sandbox/src/nhc98-1.08/src/tracer/hat' make: *** [lib/ix86-Linux/hat-stack] Error 2 It seems as if the path to `hmake' got lost somewhere. I worked around it by doing a `make install' at this point followed by another `make' (and another `make install'). Cheers, Manuel [1] You need gmp-devel to compile programs using gmp, as opposed to running programs that have been dynamically linked against gmp.

2 2

deriving Ix
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

The program import Ix newtype Name = Name Int deriving (Eq, Ord, Ix) main = print 42 gives me Error when renaming:: Identifier Ix._tupleRange used at 4:33 is not defined. Identifier Ix.inRange used at 4:33 is not defined. Identifier Ix.range used at 4:33 is not defined. Type class Ix.Ix used at 4:33 is not defined. Identifier Ix._tupleIndex used at 4:33 is not defined. Identifier Ix.index used at 4:33 is not defined. which IMO contradicts the definition of the Standard Libraries. Manuel

2 1

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> > Then I think hugs and nhc98 are wrong. The report states that the > > unliterate version of the file is recovered by "taking only > those lines > > beginning with '>', and removing the first character of > those lines", > > which would leave the lines indented by a single space, not two. > > This would appear to be an un-remarked change to the Report since > version 1.2. That version states that "program lines have the > leading '>' replaced by a leading space, to preserve tab alignments". > Version 1.3 removed this specification, and the changed specification > only appeared in Haskell'98. > > I would like to submit it as a bug in the Report - the older > specification, as implemented by Hugs and nhc98 makes more sense in > conjunction with the layout rule. I'm inclined to agree. But I'd like to know what the reason for the change in the first place was. GHC's unlit preprocessor converts the tabs to spaces in such a way that they line up after removal of the '>' characters, by the way. Cheers, Simon

1 0

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> The definitions of foo and bar are not at the same indentation level, > so they are being rejected by the layout rule. At least, hugs and > nhc98 accept it if you indent bar by two spaces, ghc still complains: > > ghc -c lit.lhs > lit.lhs:9: parse error on input `_' Then I think hugs and nhc98 are wrong. The report states that the unliterate version of the file is recovered by "taking only those lines beginning with '>', and removing the first character of those lines", which would leave the lines indented by a single space, not two. Cheers, Simon

2 1

Literate scripts not handled correctly
by Ian Lynagh 18 Sep '01

18 Sep '01

Hi all My understanding is that the following script: ----- cut here ----- > foo :: Int -> Int > foo _ = 2 \begin{code} bar :: Int -> Int bar _ = 1 \end{code} ----- cut here ----- should be valid and define foo and bar (although the report does say "It is not advisable to mix these two styles in the same file"). However, in hugs: ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") % ghc -c -o Q.o Q.lhs Q.lhs:7: parse error on input `bar' % nhc98 -c -o Q.o Q.lhs In file ./Q.lhs: 7:1 Found bar but expected a {-EOF-} Secondly, in the following script (which I think should define main according to the report): ----- cut here ----- \begin{code} module Main where main :: IO() main = putStrLn "Foo" \end{code} ----- cut here ----- hugs: ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? % nhc98 -c -o W.o W.lhs Warning: Can not find main in module Main. ghc -c -o W.o W.lhs W.lhs line 11: unlit: missing \end{code} Interestingly it works in GHC if you remove the white space before the end but not before the begin. Thanks Ian

2 1

RE: Literate scripts not handled correctly
by Simon Marlow 18 Sep '01

18 Sep '01

> My understanding is that the following script: > > ----- cut here ----- > > > foo :: Int -> Int > > foo _ = 2 > > \begin{code} > > bar :: Int -> Int > bar _ = 1 > > \end{code} > > ----- cut here ----- > > should be valid and define foo and bar (although the report > does say "It > is not advisable to mix these two styles in the same file"). > > However, in hugs: > ERROR Q.lhs:7 - Syntax error in input (unexpected symbol "bar") This is probably due to layout. The unliterate version of the file would be foo :: Int -> Int foo _ = 2 bar :: Int -> Int bar _ = 1 so the occurrence of the token 'bar' at a column less than that of the first 'foo' causes a close brace to be inserted by the layout system, closing the top-level declaration group. > Secondly, in the following script (which I think should define main > according to the report): > > ----- cut here ----- > > \begin{code} > > module Main where > > main :: IO() > main = putStrLn "Foo" > > \end{code} > > ----- cut here ----- > > hugs: > ERROR W.lhs:12 - Empty script - perhaps you forgot the `>'s? > > % nhc98 -c -o W.o W.lhs > Warning: Can not find main in module Main. > > ghc -c -o W.o W.lhs > W.lhs line 11: unlit: missing \end{code} > > Interestingly it works in GHC if you remove the white space before the > end but not before the begin. Yes, it looks like GHC's unlit program removes whitespace when looking for \begin{code}, but not for \end{code}. The report isn't explicit about whether whitespace is allowed on these lines, but I would tend to the view that it isn't. Cheers, Simon

1 0

Type error type clash between Prelude.SR and Prelude.R
by Ian Lynagh 17 Sep '01

17 Sep '01

Not sure if this is related to my previous mail about negate, but that got in the way when I was trying to work out what was going on. nhc98 -T +RTS -K11048576 -RTS -c -o Mangle.T.o Mangle.lhs ==================================== Error after type deriving/checking: Type error type clash between Prelude.SR and Prelude.R when trying to apply function at 68:28 to its 1:st argument at 68:29. Type error type clash between Prelude.SR and Prelude.R when trying to apply function at 65:28 to its 1:st argument at 65:29. Lines 64 to 58 of Mangle.lhs are > -- If there is a digit then grab it > get_infixes m (Just (it, -1)) (Number ([c]):ts) > = get_infixes m (Just (it, ord c - ord '0')) ts > -- Otherwise default to 9 > get_infixes m (Just (it, -1)) ts = get_infixes m (Just (it, 9)) ts I can put the whole file somewhere if you need it. Thanks Ian

2 2

Re: [nhc-bugs] PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base'
by malcolm＠cs.york.ac.uk 17 Sep '01

17 Sep '01

> PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base' > PC_base.z.o(.data+0x3c): undefined reference to `TMSUB_PC_95base' I suspect this is a fault in the name-mangling part of our time profiler. Try renaming the module so that it does not have an underscore in it! (both the filename and the module name I guess.) Regards, Malcolm

2 1

negate problems?
by Ian Lynagh 17 Sep '01

17 Sep '01

Various small changes work, but this doesn't: > module Main where > main :: IO() > main = putStrLn $ show $ foo 1 > foo :: Int -> Int > foo (-1) = 6 > foo i = i Compiling it gives nhc98 -c -o Q.o Q.lhs ==================================== Error when renaming:: Unbound Identifier - at 8:8 [Leaf2 ((Prelude._x,Identifier),160) followed by more stuff that I can give you if you need it and can't reproduce the problem. Thanks Ian, on a roll tonight...

2 1

PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base'
by Ian Lynagh 14 Sep '01

14 Sep '01

Hi again... What is the cause of these errors? Without -t it compiles fine, as does a tiny test program with -t. I can make the source available if needed, but it is large and I suspect I'm doing something silly. HFLAGS="+RTS -K11048576 -RTS -nkpat" hmake -t -nhc98 main nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Tokens.z.o Tokens.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o PC_base.z.o PC_base.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o PC.z.o PC.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Parser.z.o Parser.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Mangle.z.o Mangle.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Offside.z.o Offside.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Scanner.z.o Scanner.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o Args.z.o Args.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -c -o main.z.o main.lhs nhc98 -t +RTS -K11048576 -RTS -nkpat -o main PC_base.z.o PC.z.o Parser.z.o Mangle.z.o Offside.z.o Scanner.z.o Tokens.z.o Args.z.o main.z.o PC_base.z.o(.data+0x8): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x3c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0xa0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0xd0): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x124): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x158): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x1b0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x1e4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x240): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x274): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x2c8): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x304): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x390): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x3c4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x424): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x458): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x4f0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x524): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x5b4): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x5e4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x618): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x64c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x688): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x6bc): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x75c): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x788): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x7b4): undefined reference to `TMSUB_PC_95base' PC_base.z.o(.data+0x7e0): undefined reference to `TM_PC_95base' PC_base.z.o(.data+0x814): undefined reference to `TMSUB_PC_95base' collect2: ld returned 1 exit status Thanks Ian

1 0

Bug in pattern matching with nkpat
by Ian Lynagh 14 Sep '01

14 Sep '01

Hi all With the following code nhc98 prints 7, not 6 as I'd expect (and hugs does). module Main where data Wibble = Foo | Bar main :: IO() main = putStrLn $ show $ foo 1 Bar foo :: Int -> Wibble -> Int foo (n+1) Foo = 5 foo (n+1) Bar = 6 foo _ _ = 7 Thanks Ian

2 2