RE: compiling GHC with a custom path to GCC
On 18 February 2005 09:42, Simon Marlow wrote: 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. I've put in a workaround for this problem, which will show up in tonight's STABLE snapshot. It works for me on FreeBSD 4.11 with gcc 2.95.4. 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
Remi Turk wrote: [...] 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 [...] Slightly off-topic: You don't need --enable-hopengl anymore when compiling GHC 6.4 or the CVS HEAD, the OpenGL/GLUT/OpenAL packages are automatically enabled when autoconf finds the suitable libraries and headers. If you don't want that, you can use --disable-opengl, --disable-glut and/or --disable-openal. Cheers, S. ___ 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 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 ___ 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 18 February 2005 09:38, Remi Turk wrote: On Thu, Feb 17, 2005 at 11:29:41AM -, 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 ___ 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 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 Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. You know that isn't true. You can, on the same machines, compile the same code with a different compiler hundreds of times (which I did; I left it running on two machines for a month) without a single problem. That is a software problem. I make a living by determining whether problems are software or hardware, and I very rarely make a mistake. I certainly never make a mistake with this sort of overwhelming proof. You are just ignoring the things that I've said that don't fit your theory. You will not find a single case of this caused by hardware, because if the hardware is really responsible, it is 100% impossible that every other program, including programs that consume all the memory and most of the swap (consume more total memory than the gcc runs) always work perfectly, and only gcc causes this supposedly hardware problem to appear. 100 machines, of six different microprocessors, and six different types of memory, all have a hardware problem that causes gcc, and only gcc, and absolutely nothing other than gcc, to crash? These machines can otherwise run for months at a time at very high load and the hardware problem somehow never appears? Tell me that you've ever seen a hardware problem with these characteristics. Furthermore, tell me that you've seen hardware problems that never get worse, and are associated with a single program. Find a single example of such a program that reveals a hardware problem in processors made by three different companies. Or an example of a program that reveals a hardware problem in a dozen different motherboards. None of which exhibit even the slightest problem unless gcc is running. None of which deadlock, freeze up, never have kernel panics ... it just isn't possible, unless you ignore the evidence. And the fact that one is deterministic implies that the others are not? That has absolutely no basis in logic. I'm sure that with enough work each and every one can be produce deterministically. Nobody has paid me to do that, and nobody is going to. It's a lot cheaper to just use a compiler that works. Even having to use Sun's compiler, with all it's problems, is less expensive then trying to fix gcc, and Sun charges about 3,000 each for the compiler. Hardware problems cause random problems, and any problem that occurs with only one program is by definition not random. You are confusing random with not yet explained. The two aren't remotely alike. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4215baf2198669959829382! ___ 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: Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. You know that isn't true. You can, on the same machines, compile the same code with a different compiler hundreds of times (which I did; I left it running on two machines for a month) without a single problem. That is a software problem. OK, calm down. I, for one, suggested the possibility of a hardware fault because your original message on the subject of gcc crashes did not mention the possibility at all, and I thought perhaps it was a factor you had not considered. Obviously you have indeed considered it in quite some detail, and concluded that hardware is not a factor here. But because we didn't know that, the suggestion was intended to help you explore new avenues to tracking down the fault, not to annoy you. 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
On 18 February 2005 10:17, Seth Kurtzberg wrote: Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. I'm not *claiming* anything about your case - please read what I said. I simply commented that random crashes in gcc are often caused by hardware failure. Indeed it sounds like hardware isn't the problem in your case, so I suggest you try to narrow down the problem and submit a report to the gcc folks. 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 18 February 2005 10:17, Seth Kurtzberg wrote: Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. I'm not *claiming* anything about your case - please read what I said. I simply commented that random crashes in gcc are often caused by hardware failure. Indeed it sounds like hardware isn't the problem in your case, so I suggest you try to narrow down the problem and submit a report to the gcc folks. Cheers, Simon The gcc folks know about the problem, they just don't know how to fix it. I've sent them about 30 core files and many valgrind runs showing heap corruption. I have actually never seen a random crash in gcc, with a coherent core dump file, caused by hardware. This is much much too regular to even suspect hardware. You also have the fact that these machines can run ghc or ghci all day long. ghc is a heavier user of resources, and a much more complex program, but it never crashes these systems (except occasionally during these initial release or pre-release periods, which is of course to be expected). _If_ a random crash were caused by hardware, other programs would _always_ occasionally crash. There are no exceptions to this rule, unless you never run any program other than gcc that uses significant resources (and even then I'd be dubious). It's been happening for so long, and the gcc people have no concept of what's happening, so people don't even bother to report it anymore. Gcc 3.1 and 3.2 were simply rejected by almost all users because of the frequency of crashes. With 3.3, the crashes did not disappear, but became less common. The initial 3.4 release was unusable. All of these things are well known to anyone working on a C++ project. I would think that, in addition to showing the ghc is a far superior piece of software, the fact that ghc or ghci, once built, never crashes would eliminate any doubt about whether the problem is caused by hardware or software. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4215dcff207641880317564! ___ 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: 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: 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: 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_
}
