RE: compiling GHC with a custom path to GCC

newer
RE: compiling GHC with a custom...

older
RE: Increasing heap size

Simon Marlow

17 Feb 2005 17 Feb '05

6:54 a.m.

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

Show replies by date

Seth Kurtzberg

17 Feb 17 Feb

7 a.m.

New subject: 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!

Malcolm Wallace

7:15 a.m.

New subject: compiling GHC with a custom path to GCC

Seth Kurtzberg 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

Seth Kurtzberg

7:21 a.m.

New subject: compiling GHC with a custom path to GCC

Malcolm Wallace wrote:

...

Seth Kurtzberg 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!

Seth Kurtzberg

7:22 a.m.

New subject: compiling GHC with a custom path to GCC

Malcolm Wallace wrote:

...

Seth Kurtzberg 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!

Seth Kurtzberg

7:34 a.m.

New subject: compiling GHC with a custom path to GCC

Malcolm Wallace wrote:

...

Seth Kurtzberg 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!

7398

Age (days ago)

7398

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Malcolm Wallace
Seth Kurtzberg
Simon Marlow