- Glasgow-haskell-users

RE: compiling GHC with a custom path to GCC
by Simon Marlow 18 Feb '05

18 Feb '05

On 17 February 2005 11:12, Remi Turk wrote: > when compiling the new ghc pre-releases made my gcc 2.95.3 die > with "internal compiler error", I tried to compile it with gcc > 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that > died, compiled+installed gcc 3.4.3, tried again, say it die again > and only then noticed it was actually still using 2.95.3 ;) but > had quite some difficulty to actually get it to compile with, in > my case, /usr/local/bin/gcc3 > > When using the following command-line > > CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl > --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 > > stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc > that's documented) Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here? I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. Cheers, Simon

4 8

compiling GHC with a custom path to GCC
by Remi Turk 18 Feb '05

18 Feb '05

Hi, when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3 When using the following command-line CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented) I had to prepend a custom directory with `gcc' a symlink to `/usr/local/bin/gcc3' to its PATH to be able to compile the thing. Is there any other/better way? Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it.

2 1

Re: compiling GHC with a custom path to GCC
by Seth Kurtzberg 17 Feb '05

17 Feb '05

Remi Turk wrote: >On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote: > > >>On 17 February 2005 11:12, Remi Turk wrote: >> >> >> >>>when compiling the new ghc pre-releases made my gcc 2.95.3 die >>>with "internal compiler error", I tried to compile it with gcc >>>3.4.3 (or rather, I thought it compiled with 3.4.1, and when that >>>died, compiled+installed gcc 3.4.3, tried again, say it die again >>>and only then noticed it was actually still using 2.95.3 ;) but >>>had quite some difficulty to actually get it to compile with, in >>>my case, /usr/local/bin/gcc3 >>> >>>When using the following command-line >>> >>>CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl >>>--prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 >>> >>>stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc >>>that's documented) >>> >>> >>Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a >>bug here? >> >>I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look >>into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. >> >>Cheers, >> Simon >> >> > >In case you've got nothing else left to do.. ;) > >The ghc command which perfectly repeatable kills gcc: > >make[2]: Entering directory `/var/tmp/ghc-6.4.20050216/ghc/compiler' >../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package unix -package readline -DUSE_READLINE -package Cabal -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -c cmm/MachOp.hs -o stage2/cmm/MachOp.o -ohi stage2/cmm/MachOp.hi >/tmp/ghc32662.hc: In function `s5dU_ret': >/tmp/ghc32662.hc:11210: Internal compiler error in `build_insn_chain', at global.c:1756 > > At least this proves that it isn't a hardware problem. :) >The dying gcc command: > >gcc -x c cmm/MachOp.hc -o /tmp/ghc15388.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -ffloat-store -I cmm -I stage2 -I . -I codeGen -I nativeGen -I parser -I /var/tmp/ghc-6.4.20050216/libraries/readline/include -I /var/tmp/ghc-6.4.20050216/libraries/unix/include -I /var/tmp/ghc-6.4.20050216/libraries/base/include -I /var/tmp/ghc-6.4.20050216/ghc/includes > >The (naively) relevant part of the generated HC-file appears to >be the next "function". I have no idea whether this is of any >help for nailing this kind of nastiness down, so I'm not going to >spend more of my night on it ;) > >I did attach the complete failing HC-file. > >Greetings, >Remi > >// compile code which doesn't seem to matter for the crash >#define FOO 0 >// compile The Killing Line >#define BAR 1 >IF_(s5dU_ret) { > W_ _c5ec; > FB_ >#if FOO > _c5ec = (W_)((*((StgWord16*)((*R1.p) + (-0x2))))); >#endif >#if BAR > if (_c5ec < 0x5) goto _c5en; >#endif >#if FOO > if (_c5ec > 0x16) goto _c5eo; > if (_c5ec < 0x14) goto _c5ep; > switch (_c5ec-20) { > case 0x0: goto _c5eq; > case 0x1: goto _c5er; > case 0x2: goto _c5es; > } >#endif > _c5eo: >#if FOO > R1.p = (P_)(W_)GHCziBase_False_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x10)))) + (*Sp)); > _c5et: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); >#endif > _c5eu: >#if FOO > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5ev: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5ew: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5ex: > if (_c5ec != 0x5) goto _c5eo; > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5eq: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5er: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5es: > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5ep: > if (_c5ec > 0x9) goto _c5eo; > if (_c5ec < 0x9) goto _c5ex; >#endif > R1.p = (P_)(W_)GHCziBase_True_closure; > Sp=Sp+1; > JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); > _c5en: > switch (_c5ec) { >#if FOO > case 0x0: goto _c5et; > case 0x1: goto _c5eo; > case 0x2: goto _c5eu; > case 0x3: goto _c5ev; > case 0x4: goto _c5ew; >#else > case 0x0: goto _c5eo; > case 0x1: goto _c5eo; > case 0x2: goto _c5eu; > case 0x3: goto _c5eo; > case 0x4: goto _c5eo; >#endif > } > FE_ >} > > > >

1 0

RE: compiling GHC with a custom path to GCC
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 12:43, Seth Kurtzberg wrote: > Simon Marlow wrote: > >> On 17 February 2005 12:05, Seth Kurtzberg wrote: >> >> >> >>> I'm not positive about 2.95, but I know that on 3.x it crashes in >>> different places, and even compiling different source files. With >>> each 3.x release, they fix some of them, but others pop up to take >>> their place. Clearly the gcc people don't know what's going on. >>> >>> >> >> Are you sure this isn't a hardware problem on your system? gcc >> crashing randomly is usually an indicator of bad memory or similar. >> >> Cheers, >> Simon >> >> > I reproduced it on forty machines, all sparc ultras. I've reproduced > it > on at least 10 linux boxes, two BSD boxes, and the thread started with > the problem on freeBSD. It isn't hard to find the error on a zillion > pages. For example: > > For example: > http://sources.redhat.com/ml/cygwin/1999-03/msg00083.html > http://www.cygwin.com/ml/cygwin/2002-01/msg00611.html > http://www.winehq.org/hypermail/wine-users/2000/12/0498.html > > Some of these believe the error occrs on cc1 after it receives an > error six. > > I'm amazed that you haven't seen it. That's very unusual for gcc 3.x. > You've been lucky. You're mixing up different errors - searching for 'gcc internal error' isn't particularly helpful. gcc internal errors happen for lots of different reasons, not just a single bug. Random unrepeatable crashes are almost certainly hardware failure. The crash on FreeBSD we were talking about earlier is repeatable, and only happens with GCC 2.95.x. The crash that happens on your 40 Sparc Ultras is repeatable, right? It's probably just a compiler bug in the particular version of gcc you're using. Cheers, Simon

2 1

Fixing Parser.y for correct infix type synonyms
by Johan Glimming 17 Feb '05

17 Feb '05

Hi I am looking into the ghc source code for the first time in order to see if I can understand why type synonyms are not correctly parsed with the ghc extension for infix :-*-: etc. I note that the following is present in the file Parser.y in ghc-6.4.20050216/ghc/compiler/parser and I assume it here ghc is parsing the type declarations? tycl_decl :: { LTyClDecl RdrName } : 'type' syn_hdr '=' ctype -- Note ctype, not sigtype. -- We allow an explicit for-all but we don't insert one -- in type Foo a = (b,b) -- Instead we just say b is out of scope { sL (comb2 $1 $>) $ let (tc,tvs) = $2 in TySynonym tc tvs $4 } on the next line happy is probably given instructions how to parse data declarations? | 'data' tycl_hdr constrs deriving { L (comb4 $1 $2 $3 $4) (mkTyData DataType $2 Nothing (reverse (unLoc $3)) (unLoc $4)) } Now, can someone explain what happens here, e.g. what is the difference between parsing of data and type synonyms? I guess (!) that the handling of infixes is merely an issue in the parser, and would not affect much else in ghc? Johan Glimming.

1 0

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 16:25, Georg Martius wrote: > Another bug in ghc! >> /usr/bin/ghc -M wxcore/src/Graphics/UI/WXCore/WxcClassTypes.hs \ >> -iout/wxcore/imports -Iwxc/include -iwxcore/src \ >> -odir out/wxcore/imports/Graphics/UI/WXCore/ produces (among >> others): >> out/wxcore/imports/Graphics/UI/WXCore//Graphics/UI/WXCore/WxcClassTypes. o >> : \ wxcore/src/Graphics/UI/WXCore/WxcClassTypes.hs > where you see that the -odir is not handled correctly. This is correct behaviour for -odir. The docs describe it: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html Cheers, Simon

2 1

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 14:54, Daan Leijen wrote: >> A more general question: We doesn't -ohi dir/filename.hi is not >> reflected in the dependencies. >> I tried: >> >>> ghc -M -odir out -ohi out/A.hi A.hs >> >> but nothing changed. > > Simon?? This is because ghc -M works like --make, in that it traverses the module dependency graph. When multiple modules are being considered, the -ohi flag doesn't make much sense (which module does it apply to?). The right way is to use -hidir/-hisuf, which are honoured by -M and --make. Cheers, Simon

2 1

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 13:48, Daan Leijen wrote: > Secondly, maybe ghc should not generate the spurious extra rules? > (and generate exactly what it generated at version 6.2.2). What do > you think Simon? ghc -M now works like --make and GHCi: it follows dependencies. In fact, it's using the same code internally (previously there was some duplication). Partly the reason for this change was we needed enhancements to the dependency tracking for the new .hs-boot mechanism. There's no way to make ghc -M *not* follow dependencies. I assume that what you're doing is generating dependencies for each source file separately, right? I wonder if perhaps we should have a way to prevent ghc -M from generating dependencies on files that aren't explicitly mentioned on the command line. >> 3. Package stuff >> I included package files in the new style to the configure script. >> Problem: the environment variable are not substituted any longer by >> ghc-pkg ? > > Simon? That's right, I was too lazy to implement it, and in any case it's slightly dubious - the expansion happened after parsing, so can an environment variable expansion result in multiple list items? Mostly we pre-process our package.conf files using CPP instead of using environment variables, or we use autoconf. Could you do that? Cheers, Simon

1 0

Re: ghc-cvs-snapshot with wxHaskell
by Georg Martius 17 Feb '05

17 Feb '05

Hi, Patrick and I found some answers to the questions/problems we encountered. Finally got the thing to work. (patches appended) Versions: ghc-6.4.20050215 wxHaskell-0.8. 1. dep-files the new ghc produces a different dependency file. It includes also dependencies for imported modules. i.e. > module A import B it generates: > B.o : B.hs > A.o : A.hs > A.o : B.hi where as the old ghc omitted the first line, which is not necessary IMO. The problem with the wx-Makefile is now that the .o and .hi files should reside in another directory namely out/... The current approach is to use "sed". However on the new depfiles it generates rules, which are not correct and which lead to the problems Patrick experiences. I have a possible fix: add -odir out/... to the call of ghc -M. This produces correct paths for the .o files. use "grep" to filter module A Problem: the .hi files have still the source path. Question @Daan: Why do they have to by in out/...? It seams to complicate the thing. Solution: "sed" I fixed that in "makefile.lib". Now the dependency stuff seams to work fine. No double compilation anymore. 2. correct import-search path the make file calls ghc from the wxHaskell-root. Therefore -icurrent/source/path has to be included. I fixed that in "makefile". 3. Package stuff I included package files in the new style to the configure script. Problem: the environment variable are not substituted any longer by ghc-pkg ? My hack: let configure sustitude the variable, i.e. configure:750 > wxhlibdir="${libdir}" . . > import-dirs: ${wxhlibdir}/imports instead of > import-dirs: \${wxhlibdir}/imports This might cause problems with the rpm install stuff. Additionally, I had problems with the license field. It seams to be a choice rather a text-field. I took BSD3 since it worked. @Simon: How can I add a custom license like "wxWindows" @Daan: Please complete the package files. There are a couple of new entries. Also some exports from wxcore might be better in the hidden-modules field. Honestly I have no idea where it is for. A had to add a > extra-libs : wxc-gtk2.4.2-0.8 to wxcore package info. This seams not quite portable :-). @Daan: please replace this by a proper variable 4. Module name clash ghc complained: wxdirect/src/Set.hs:1:0: Module `Set' is a member of package data-1.0. To compile this module, please use -ignore-package data-1.0. I love ghc's error messages! Great job Simon! @Daan: the configure script uses /usr as a default prefix. I think /usr/local is more standard here. Additionally the modules are installed to <prefix>/lib/imports. I would rather like <prefix>/lib/wxHaskell/imports. How do we make sure that nobody else wants to use the path lib/imports? This is a fairly common, or at least non-specific, directory name in my eyes. Cheers, Georg On Thu, 17 Feb 2005 00:44:23 +0100, Patrick Scheibe <mai99dnn(a)studserv.uni-leipzig.de> wrote: > On Wednesday 16 February 2005 16:48, you wrote: >> Hi Simon and Daan. >> >> I took the stable ghc source from yesterday, 15th of february. >> I think Simon fixed the creation of .depfiles problem, am I right? >> Touching of these files is unnecessary now. >> >> In earlier versions the ghc seems to make the right thing when you call >> ghc -M ./dir1/dir2/src/Moduldir/Modul.hs >> >> Now there are errors when you call it from outside the modulpath: >> > Could not find module `ParseEiffel': >> > use -v to see a list of the files searched for >> > (imported from wxdirect/src/CompileDefs.hs) >> >> I fixed this with giving the -i./dir1/dir2/src option to every call. >> @Simon: is this a feature? Do I make something strange with this fix? >> >> Now the compilation runs fine (:-) but when I do a make install, the >> makefile begins to compile again!?? After a while of compilation it breaks >> with a "no rule to make.." error. How can ghc forget the compiled stuff? >> The objects are definitely there, so there is no need to recompile WX.o, >> ... >> >> @Daan: I tried to delete the dependency wx from the install rule of the >> makefile but that >> doesn't matter. I would like to install it by myself to see if the lib is >> working. Do you have a quick bad fix of this? >> >> Cheers >> Patrick > -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

2 4

RE: compiling GHC with a custom path to GCC
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 12:54, Seth Kurtzberg wrote: > Here are the bug reports: > http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_statu s=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=WAITING&bug_sta tus=SUSPENDED&field0-0-0=product&type0-0-0=substring&value0-0-0=internal &field0-0-1=component&type0-0-1=substring&value0-0-1=internal&field0-0-2 =short_desc&type0-0-2=substring&value0-0-2=internal&field0-0-3=status_wh iteboard&type0-0-3=substring&value0-0-3=internal&field1-0-0=product&type 1-0-0=substring&value1-0-0=compiler&field1-0-1=component&type1-0-1=subst ring&value1-0-1=compiler&field1-0-2=short_desc&type1-0-2=substring&value 1-0-2=compiler&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0 -3=compiler&field2-0-0=product&type2-0-0=substring&value2-0-0=error&fiel d2-0-1=component&type2-0-1=substring&value2-0-1=error&field2-0-2=short_d esc&type2-0-2=substring&value2-0-2=error&field2-0-3=status_whiteboard&ty pe2-0-3=substring&value2-0-3=error Zarro Boogs found. Cheers, Simon

1 0