February 2005 - Glasgow-haskell-users

RE: Restricted Types and Infinite Loops
by Simon Peyton-Jones 18 Feb '05

18 Feb '05

Simon You've found an interesting case. First, you are skating on thin ice here. GHC's ability to build recursive dictionaries is quite experimental, and you are relying on it completely. But you're right: it "should" work. I can see why it isn't but I have not got it clear enough in my head to know the best way to fix it. Still less do I have a formal story about what should type-check (without loops) and what should not. So this is going to continue to fail in 6.4, but it's on my list to look at. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Simon David Foster | Sent: 27 January 2005 14:11 | To: GHC Users | Subject: Restricted Types and Infinite Loops | | Hi, | | (I've attached the full code for this problem) | | First I'll explain the problem description, I have two class ClassA and | ClassB, the former has two parameters and the latter has one. The second | parameter of ClassA is constrained by ClassB. | | class ClassB a where | class ClassB b => ClassA a b where | | Because I wish to effectively pass the context of ClassA around, I need | to create a pair of dictionary types (as in Restricted Data Types in | Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to | represent ClassB (DictClassB). DictClassA also contains a term of type | DictClassB since ClassA is a subclass of ClassB. I should then be able | to call all the functions of ClassB via the appropriate term of | DictClassA, like so (assuming we want to use func2); | | *Test> func2D (classBD (dict::DictClassA Int String)) "hello" | "bye" | | So far so good, but now suppose I want Class A to have the further | constraint | | class (Data (DictClassA a) b, ClassB b) => ClassA a b where | | (so as to make ClassA a subclass of Data) | | If we now try and do | | *Test> func2D (classBD (dict::DictClassA Int String)) "hello" | | We go into an infinite loop. Why? The expression still type-checks ok | and I can't see what it is trying to do. All the functions of ClassA can | be accessed ok, but not ClassB. | | *Test> funcD ((dict::DictClassA Int String)) "hello" 5 | "hello" | | Is it something to do with ClassB only having one parameter? | | I'm running GHC 20041231. | | -Si. | | -- | Simon David Foster <s.d.f(a)btinternet.com>

2 1

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

18 Feb '05

On 17 February 2005 20:24, Georg Martius wrote: > 2. Stub files (@Simon) > The problem I ran into was that the FILE_stub.o files are not placed > at the correct(?) directory according to the position of FILE in the > hierarchical library. > Example: > ghc -c wxcore/src/Graphics/UI/WXCore/Events.hs -o > out/wxcore/imports/Graphics/UI/WXCore/Events.o -fvia-C -package-name > wxcore -iwxcore/src -odir out/wxcore/imports -hidir > out/wxcore/imports -iout/wxcore/imports -Iwxc/include > > produces > out/wxcore/imports/Events_stub.o > instead of > out/wxcore/imports/Graphics/UI/WXCore/Events_stub.o > I don't know if it is the expected behaviour? I just looked at the code, this is a can of worms. I don't think I can fix it this close to the release without breaking anything else, so if you can manage with this behaviour then I'll leave it as is. Later, we can try to determine what the right behaviour should be with respect to stub files and the interactions with --make, hierarchical modules and -odir. Right now it's making my head hurt a bit. Cheers, Simon

1 0

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

18 Feb '05

On 18 February 2005 04:26, Seth Kurtzberg wrote: > At least this proves that it isn't a hardware problem. :) Seth, you're a bit confused. This error from gcc is a deterministic, repeatable, crash due to a known bug in gcc 2.95. You were complaining about random unrepeatable crashes, which are most likely caused by hardware failure. We never said that deterministic crashes in gcc are due to hardware. Cheers, Simon

3 2

Restricted Types and Infinite Loops
by Simon David Foster 18 Feb '05

18 Feb '05

Hi, (I've attached the full code for this problem) First I'll explain the problem description, I have two class ClassA and ClassB, the former has two parameters and the latter has one. The second parameter of ClassA is constrained by ClassB. class ClassB a where class ClassB b => ClassA a b where Because I wish to effectively pass the context of ClassA around, I need to create a pair of dictionary types (as in Restricted Data Types in Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to represent ClassB (DictClassB). DictClassA also contains a term of type DictClassB since ClassA is a subclass of ClassB. I should then be able to call all the functions of ClassB via the appropriate term of DictClassA, like so (assuming we want to use func2); *Test> func2D (classBD (dict::DictClassA Int String)) "hello" "bye" So far so good, but now suppose I want Class A to have the further constraint class (Data (DictClassA a) b, ClassB b) => ClassA a b where (so as to make ClassA a subclass of Data) If we now try and do *Test> func2D (classBD (dict::DictClassA Int String)) "hello" We go into an infinite loop. Why? The expression still type-checks ok and I can't see what it is trying to do. All the functions of ClassA can be accessed ok, but not ClassB. *Test> funcD ((dict::DictClassA Int String)) "hello" 5 "hello" Is it something to do with ClassB only having one parameter? I'm running GHC 20041231. -Si. -- Simon David Foster <s.d.f(a)btinternet.com>

3 6

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

18 Feb '05

On 18 February 2005 09:38, Remi Turk wrote: >>> On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote: >>>> 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. > > (though I now assume it probably isn't even the same bug?) Yes, it's the same bug. Simon

1 0

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

18 Feb '05

On 18 February 2005 01:02, Donald Bruce Stewart wrote: > This is a known problem with gcc-2.95. > We came across it back in September. > > It was noticed in the nightly builds: > > http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html > > And then we chased it up: > > http://www.haskell.org/pipermail/cvs-all/2004-September/035122.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035134.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035259.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035268.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035293.html Don, thanks for the pointer, I'd completely forgotten about that. I think I'll be able to install a workaround for 6.4 based on the gcc version. I need it at least because FreeBSD 4.x still uses gcc 2.95, and AFAIK quite a few folks are still using that platform. Cheers, Simon

1 0

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 18 Feb '05

18 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