RE: GHC-problem with parsing infix type synonyms - bug?
On 16 February 2005 14:41, Johan Glimming wrote: I read from the type-extensions.html part of the GHC 6.2 manual: After expanding type synonyms, GHC does validity checking on types, looking for the following mal-formedness which isn't detected simply by kind checking: ... Partially-applied type synonym. However, when entering: infix 9 :-+-: type (f :-+-: g) t o1 o2 = Either (f t o1 o2) (g t o1 o2) or simpler variations e.g. without brackets, except where no arguments are present after (f :-+-: g), I get parse errors (yes, _parse_) on this very line. Also, the above works for data, and the lexical syntax is the same as that for data constructors [someone had read this somewhere]. I think the syntax used in your type synonym declaration isn't supported at the moment. For consistency it probably should be. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-problem with parsing infix type synonyms - bug?
I think the syntax used in your type synonym declaration isn't supported at the moment. For consistency it probably should be. Is there any chance to fix this in the next 6.4 release, or can I patch 6.4 myself? (I'd need hints though.) I have some code in a project for which I want to use type synonyms for instead of data type definitions, to save on all the constructor names hanging around. Johan Glimming. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Increasing heap size
Actually you need to use the -M option to increase the heap size beyond this limit on Windows. I'll see if I can fix the message. Thanks for your answer! I tried to use option +RTS -c -RTS and then it worked without changing the heap size (AFAIK this switches garbage collection to a more efficient algorithm). Best regards Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Increasing heap size
On 17 February 2005 10:55, Dmitri Pissarenko wrote: Actually you need to use the -M option to increase the heap size beyond this limit on Windows. I'll see if I can fix the message. Thanks for your answer! I tried to use option +RTS -c -RTS and then it worked without changing the heap size (AFAIK this switches garbage collection to a more efficient algorithm). Using +RTS -c -RTS turns on in-place compacting collection, which will use less memory but takes longer. If you use +RTS -Msize -RTS, then GHC will automatically turn on compacting collection when the program's memory requirements approach size. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
compiling GHC with a custom path to GCC
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiling GHC with a custom path to GCC
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
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. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421483e7114671125015511! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiling GHC with a custom path to GCC
On 17 February 2005 11:49, Seth Kurtzberg wrote: 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. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. A known problem? Is there any open bug in the gcc bug database I can look at? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote: 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. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. Cheers, Simon I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun... Anyway, I just replaced a ifneq $(INSTALL_LIBS) by ifneq $(strip $(INSTALL_LIBS)) (see my glasgow-haskell-bugs message of today, this usage is recommended in make's info for strip.) Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I remember that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.) -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 17 February 2005 11:49, Seth Kurtzberg wrote: 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. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. A known problem? Is there any open bug in the gcc bug database I can look at? There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. The compiler is broken, but since you can recover by restarting the make, it isn't horrible, just almost horrible. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421489b7116526977230217! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cvs-snapshot with wxHaskell
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 [EMAIL PROTECTED] 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 -
configure.diff
Description: Binary data
makefile.diff
Description: Binary data
makefile.lib.diff
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Remi Turk wrote: On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote: 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. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. Cheers, Simon I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun... Anyway, I just replaced a ifneq "$(INSTALL_LIBS)" "" by ifneq "$(strip $(INSTALL_LIBS))" "" (see my glasgow-haskell-bugs message of today, this usage is recommended in make's "info" for strip.) Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I "remember" that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.) 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiling GHC with a custom path to GCC
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
On Thu, Feb 17, 2005 at 05:05:18AM -0700, Seth Kurtzberg wrote: Remi Turk wrote: I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun... Anyway, I just replaced a ifneq $(INSTALL_LIBS) by ifneq $(strip $(INSTALL_LIBS)) (see my glasgow-haskell-bugs message of today, this usage is recommended in make's info for strip.) Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I remember that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.) 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. Sounds like it just was about time to get a C-- backend ;o) [off-topic] Btw, how bad is it to get Bad eta expand warnings during compilation of GHC? Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Seth Kurtzberg [EMAIL PROTECTED] writes: There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. Sounds like a CPU-overheating problem to me. It is well known that running an inadequately cooled processor at 100% for an extended period will cause random crashes. There are third-party reports that it happens with Linux kernel builds, and I have personally seen it with builds of nhc98 and Hat. When I replaced the CPU fan, the problems disappeared. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Non-repeatable crashes certainly point the finger first at hardware rather than software. Could also be deteriorating memory chips - but that is likely to bring the whole machine down eventually. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Malcolm Wallace wrote: Seth Kurtzberg [EMAIL PROTECTED] writes: There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. Sounds like a CPU-overheating problem to me. It is well known that running an inadequately cooled processor at 100% for an extended period will cause random crashes. There are third-party reports that it happens with Linux kernel builds, and I have personally seen it with builds of nhc98 and Hat. When I replaced the CPU fan, the problems disappeared. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Non-repeatable crashes certainly point the finger first at hardware rather than software. Could also be deteriorating memory chips - but that is likely to bring the whole machine down eventually. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f7e119355211311528! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Malcolm Wallace wrote: Seth Kurtzberg [EMAIL PROTECTED] writes: There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. Sounds like a CPU-overheating problem to me. It is well known that running an inadequately cooled processor at 100% for an extended period will cause random crashes. There are third-party reports that it happens with Linux kernel builds, and I have personally seen it with builds of nhc98 and Hat. When I replaced the CPU fan, the problems disappeared. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Non-repeatable crashes certainly point the finger first at hardware rather than software. Could also be deteriorating memory chips - but that is likely to bring the whole machine down eventually. Regards, Malcolm Ordinally I would agree, but in this cases it hash to be software because I got probem on 40 different solais system As for the processor overheating, you would expect that it's on it's last legs if it starts overheating. It also happens on older machies; I've seen it happen on a PII machine, which isn't terribly hot. I think that because I've seen it so many times, on machines that continue to run flawlessly, some for two years, we can eliminate hardware. This is almost certainly heap corruption. The KDE tool that is like purify (only better and free), valgrind, should help fix it if it is caused by any sort of memory corruption. That would be Remember, it is always crashing (I believe always) with an internal compiler error. Were hardware involved, you would expect to not get the same message. (Unless its the only error they have a name for). If you really want to fix it, we could use a watchdog timer, and have it restart the compiler whenever it crashes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f7e119355211311528! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f0e119011198721357! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiling GHC with a custom path to GCC
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
On Thu, Feb 17, 2005 at 11:29:41AM -, 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 I seem to have been mistaken. When configuring with --with-gcc it does use gcc 3.4.3. I'm letting it continue till completion to be entirely sure. (As IIRC the compiler-errors came rather late in the build and it's only compiling for about an hour now.) I'll try to reproduce the 2.95 internal compiler error later. Btw, at first I misunderstood the following comment in docs/building/building.xml to mean that --with-gcc only specified the compiler for actual .c files in the ghc-distribution. (Which explains my (okay, for --with-gcc that's documented)) termliteral--with-gcc=parameterpath/parameter/literal indextermprimaryliteral--with-gcc/literal/primary/indexterm /term listitem paraSpecifies the path to the installed GCC. This compiler will be used to compile all C files, emphasisexcept/emphasis any generated by the installed Haskell compiler, which will have its own idea of which C compiler (if any) to use. The default is to use literalgcc/literal./para /listitem To be more precisely, to me the installed Haskell compiler was the (stage[12] of the) Haskell compiler to be installed once it's compiled. Groeten, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cvs-snapshot with wxHaskell
On Thu, 17 Feb 2005 14:48:11 +0100, Daan Leijen [EMAIL PROTECTED] wrote:
Georg Martius wrote:
Hi,
Patrick and I found some answers to the questions/problems we encountered.
Finally got the thing to work. (patches appended)
Great!
I have a possible fix:
add -odir out/... to the call of ghc -M. This produces correct paths
for the .o files.
Ok, this makes sense and, importantly, it also works for older ghc's
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.
I do not understand what you are saying here. Can you explain in more
detail? What is the issue with .hi files?
example:
src/A.hs (import src/B.hs with import B)
ghc -M -odir out
depfile:
out/B.o: src/B.hs -- this line is new, as said before
out/A.o: src/A.hs
out/A.o: src/B.hi -- this line referes to a .hi, which is not there, it is
under out/B.hs
The original code in the makefile.lib replaced
(basename input.hs) with (basename output.o)
and
*.hi with *.o
which is a quite weird approach to the problem. I'am not sure but I think the
new approach is better:
let the .o files be correct through the -odir flag
replace (dir input)/FILE.hi with (dir output)/$FILE.o
However it is just a guess. The thing is that we have no rules for *.hs to
*.hi. If so it would be easier.
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.
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.
This is weird. It works with ghc-6.2.2, so there should not be an
extra include path. All files are referenced by absolute paths
everywhere! (that's why I use sed in the first place to process .d files)
Okay it was my fault.
If all dependencies are resolved correctly then it works fine, also with
ghc-6.4. Sorry!
The -i$({WXD|WXCORW|...}-SRCDIR) flags can be removed from the makefile.diff.
Cheers,
Georg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cvs-snapshot with wxHaskell
Hi again, Fuck! The problem is different indeed! As Patrick pointed out earlier, the problem with the import-paths is the -M run, not the normal compilation run. /usr/bin/ghc -M wxcore/src/Graphics/UI/WXCore/WxcClassTypes.hs \ -iout/wxcore/imports -Iwxc/include works fine with ghc-6.2, but ghc-6.4: Could not find module `Graphics.UI.WXCore.WxcObject' Therefore Patrick suggested to include -iwxcore/src/ However it should not be necessary for ghc, but I see why it needs it to produce the spurious line :-) Simon? 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. Now I see the reason why I added the source directories to the import search-path in general. The current appoach for the depfiles (until the -odir thing is fixed): - include -isourcepath and NO -odir - use grep to get rid of the spurious dependency lines - use the old approach for renaming (patch attached) Cheers, Georg On Thu, 17 Feb 2005 15:54:00 +0100, Daan Leijen [EMAIL PROTECTED] wrote: The original code in the makefile.lib replaced (basename input.hs) with (basename output.o) and *.hi with *.o which is a quite weird approach to the problem. I'am not sure but I think the new approach is better: let the .o files be correct through the -odir flag replace (dir input)/FILE.hi with (dir output)/$FILE.o This seems indeed much more sensible. I'll try this out with ghc 6.2.2. 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?? Thanks again for your bug fixing, -- Daan. -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net - makefile.lib.diff Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-cvs-snapshot with wxHaskell
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-cvs-snapshot with wxHaskell
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-cvs-snapshot with wxHaskell
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cvs-snapshot with wxHaskell
On Thu, 17 Feb 2005 16:36:48 -, Simon Marlow [EMAIL PROTECTED] wrote: 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. Okay that sounds reasonable. I was looking for an -odir equivalent for hi files anyway. (It was not that hard :-)). The problem with hierarchical libs remains. Example: ./out ./out/Foo ./src ./src/Foo ./src/Foo/Bar.hs module Foo.Bar where import Foo.Bla ./src/Foo/Bla.hs module Foo.Bla ghc -M -odir out/Foo/ -hidir out/Foo/ src/Foo/Bar.hs -isrc # DO NOT DELETE: Beginning of Haskell dependencies out/Foo//Foo/Bla.o : src/Foo/Bla.hs out/Foo//Foo/Bar.o : src/Foo/Bar.hs out/Foo//Foo/Bar.o : out/Foo//Foo/Bla.hi # DO NOT DELETE: End of Haskell dependencies @Daan: why don't you use --make anyway? It would make obsolete so many problems IMO. Cheers, Georg -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net - ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The GHC.PArr module [Was: Re: GHC 6.4 release candidates available]
Remi Turk rturk at science.uva.nl writes: ... I just noticed that in GHC.PArr, productP is defined wrongly productP :: (Num a) = [:a:] - a productP = foldP (*) 0 in (the likely) case that PArr is deprecated, you may want to add a DEPRECATED-pragma. I have just discovered that module recently through the paper An Approach to Fast Arrays in Haskell at http://www.cse.unsw.edu.au/~chak/papers/CK03.html I have found a bug in enumFromToP from http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ base/GHC/PArr.hs?rev=1.7 enumFromThenToP 6 5 1 == [:6,5,4:] enumFromThenToP 10 8 1 == [:10,8,6:] Mentioning this on the friendly #haskell channel got me this suggestion: TheHunter: hmm, i think enumFromThenToP = ... replicateP (((z - x) `div` delta) + 1) delta does the trick. Regards, Peter Eriksen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cvs-snapshot with wxHaskell
Hi folks, thanks to Simon for enlighten me about the correct functionality of -odir and -hidir. Now, we use -odir and -hidir for compilation as well as for dependency file generation. It seems to be a much better approach than before. However I ran into 2 problems again: 1. The cross-dependencies between wxcore and wx are wrong (@Daan) compilation of the wx with -odir out/wx/imports produces dependencies like: out/wx/import/Graphics/UI/WX/Types.hs : out/wx/import/Graphics/UI/WXCORE/Types.o where the latter not exist, since it is in out/wxcore/import/Graphics/UI/WXCORE/Types.o ^^ I don't see a way to avoid that other than direct the output of wxcore and wx to the same directory. I took out/wx_wxcore. It is not as nice as before, but I hope that is OK for you? 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? My work around is to modify the dependency in the makefile to expect it there. Now it works fine with ghc 6.2 and 6.4. The patches are attached. Cheers, Georg On Thu, 17 Feb 2005 17:04:13 -, Simon Marlow [EMAIL PROTECTED] wrote: 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 -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net - makefile.diff Description: Binary data makefile.lib.diff Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: 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. Wrong. Some are sparc 10s, 20s, ultra 10s, blades, 2000's, off the top of my head. The x86 hardware includes seven Dell machines, three machines I built, 8 compaq machines (before the merger), three HP machines, four Fujitsu laptops, and those are only the ones I remember specifically running the test on. The sparcs, especially, run for three solid months, every one of them, without a single problem or error. They are rebooted every three months as a precaution, although I think it is an unnecessary one. The only program that crashes is gcc. It makes no difference what gcc is compiling, as long as it is big. Of course, I suppose it is possible that every Pentium 3 and Pentium 4 processor, or all the PC100, single channel DDR, and dual channel memory sticks, and all the different sparc processors tested all have a hardware problem that appear only when you use gcc, but that strikes me as rather unlikely. In the face of well over 50 machines, all of which have the same problem with gcc, and none of which has a single problem with any other program (including Sun's compiler), that doesn't seem likely. The same thing is true in the machines running windows; Microsoft's compiler will build all day long, while gcc crashes. If this just happened on windows, you might question the windows gcc port, but it doesn't happen only on windows. Also, it makes no difference how many errors cause gcc to crash. If it has 1000 different bugs or one bug, it still crashes. I don't see how pretending this doesn't happen is terribly useful. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421498d8122471196589817! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
[Resent, with a few #ifdef FOO's removed from the body (still in
the attachement, and using gzip instead of bzip2 to prevent
awaiting moderation ;)]
On Thu, Feb 17, 2005 at 11:29:41AM -, 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
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 (with some code which doesn't seem to
matter for the crash removed). 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 The Killing Line
#define BAR 1
IF_(s5dU_ret) {
W_ _c5ec;
FB_
#if BAR
if (_c5ec 0x5) goto _c5en;
#endif
_c5eo:
_c5eu:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5en:
switch (_c5ec) {
case 0x0: goto _c5eo;
case 0x1: goto _c5eo;
case 0x2: goto _c5eu;
case 0x3: goto _c5eo;
case 0x4: goto _c5eo;
}
FE_
}
--
Nobody can be exactly like me. Even I have trouble doing it.
MachOp.hc.bz2
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
rturk: [Resent, with a few #ifdef FOO's removed from the body (still in the attachement, and using gzip instead of bzip2 to prevent awaiting moderation ;)] On Thu, Feb 17, 2005 at 11:29:41AM -, 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 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 The bug was dealt with in gcc-3.01 I think, and upgrading to gcc-3.3x certainly stopped it occuring in the OpenBSD nightly builds. Try adding: --with-gcc=gcc-3.x Works for me. If you really need gcc-2.95, then constructing a patch along the lines of the one proposed to solve the test case should probably do it, though it would be a pain. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Restricted Types and Infinite Loops
Hi Simon SD,
cc Simon PJ,
(Since the _evaluation_ does not terminate (rather than type checking),
this seems to imply that evaluation-time dictionary construction does
not terminate. Right?)
Anyhow, do this change, and your code works.
diff SDF.save SDF.hs
10c10
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
---
class (Data (DictClassA a) b) = ClassA a b where
*Test func2D (classBD (dict::DictClassA Int String)) hello
bye
*Test Leaving GHCi.
(BTW, this even works with GHC 6.2 as opposed to the examples from the
SYB3 paper.)
Here I assume that you don't _really_ depend on ClassB to be a
superclass of ClassA. (Why would you?)
This is a simpler recursion scheme in terrms of class/instance constraints.
Regards,
Ralf
Simon David Foster wrote:
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.
{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances #-}
module Test where
import Data.Typeable
-- Skeleton of the Data class
class (Typeable a, Sat (ctx a)) = Data ctx a
-- Our main class with 2 parameters
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
func :: b - a - String
-- The class which contrains ClassA
class ClassB a where
func2 :: a - String
data DictClassA a b = DictClassA { funcD :: b - a - String, classBD ::
DictClassB b }
data DictClassB b = DictClassB { func2D :: b - String }
class Sat a where
dict :: a
instance Sat (ctx String) = Data ctx String
-- Trying to access any of functions in ClassA works fine, but trying to get at
anything in ClassB causes and infinite loop.
instance (Data (DictClassA a) b, ClassA a b, ClassB b) = Sat (DictClassA a b)
where
dict = DictClassA { funcD = func, classBD = dict }
instance ClassB b = Sat (DictClassB b) where
dict = DictClassB { func2D = func2 }
instance ClassA a String where
func _ _ = hello
instance ClassB String where
func2 _ = bye
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Ralf Lammel
[EMAIL PROTECTED]
Microsoft Corp., Redmond, Webdata/XML
http://www.cs.vu.nl/~ralf/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Remi Turk wrote:
On Thu, Feb 17, 2005 at 11:29:41AM -, 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_
}
